Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Collecter des statistiques sur les MPLS sessions de l’année

Configuration des MPLS pour collecter les statistiques

Vous pouvez configurer MPLS de manière à collecter périodiquement des statistiques de trafic sur toutes les sessions de MPLS, y compris les sessions de transit, en configurant statistics l’instruction. Vous devez configurer l’énoncé si vous souhaitez collecter des statistiques MPLS du trafic à l’aide d’une enquête SNMP sur les bases d’informations MPLS statistics de gestion (MIM).

Pour activer ou désactiver la collecte MPLS statistiques, inclure statistics l’instruction:

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, les statistiques sont placées dans un fichier, avec file une entrée par LSP. Pendant l’intervalle spécifié, les informations suivantes sont enregistrées dans ce fichier:

  • Nombre de paquets, nombre d’octets, de paquets par seconde et d’octets par seconde transmis par chaque LSP. La parité de fonctionnalités pour l’affichage des statistiques sur les paquets et les conseils d’utilisation des sous-LSP d’un LSP point-à-multipoint sur la puce Junos Trio est prise en charge dans Junos OS Releases 11.1R2, 11.2R2 et 11.4.

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

À la fin de chaque rapport périodique, un résumé indique l’heure actuelle, le nombre total de sessions, le nombre de sessions à lire, le nombre de sessions ignorées et les erreurs de lecture, le cas cas contraire. Les sessions ignorées sont généralement celles qui ne sont pas en état de préparation ou celles qui ont un label entrant réservé (0 à 15) (généralement le point de sortie d’un LSP). Le motif 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. L’exemple de sortie suit:

Présentation des LSP à la demande pour la perte de paquets et la mesure des retards

Ce sujet décrit les méthodes permettant de mesurer la perte de paquets, les délais et le débit pour les chemins de commutation d’étiquettes (LSP) de point à point (UHP) dans les réseaux MPLS afin de surveiller les performances du réseau.

Importance de la mesure des pertes de paquets et des délais

L’essor des applications consommant de bande passante, telles que les services IPTV et les vidéos mobiles, couplée à la pression exercée pour minimiser le coût par bit et maximiser la valeur par bit, oblige les opérateurs à faire passer leurs réseaux de transport des technologies circuits vers des technologies basées sur les paquets. MPLS est une technologie de transport de paquets très efficace et orientée connexion, particulièrement adaptée aux réseaux de transport basés sur les paquets.

Avec l’émergence de nouvelles applications sur les réseaux de données, il est de plus en plus important pour les fournisseurs de services de prévoir avec précision l’impact des déploiements de nouvelles applications. Pour réussir les implémentations, il est particulièrement important de comprendre et modéliser les performances réseau dans le réseau pour déployer des applications du monde nouveau. Dans les réseaux de paquets, la perte de paquets et les délais sont deux des mesures les plus fondamentales en terme de performances. Leur rôle est encore plus central en matière de mesure de bout en bout.

Le trafic appartenant à la plupart des applications utilisateur de bout en bout est sensible aux pertes (transfert de fichiers), aux retards (applications voix ou vidéo) ou aux deux (applications informatiques interactives). Les accords de niveau de service (SA) des fournisseurs de services dépendent de leur capacité à mesurer et à surveiller ces indicateurs de performances réseau, car ils dépendent directement ou indirectement des pertes et retardent les expériences du trafic des clients 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 mesures de performance relatives aux pertes de paquets, aux délais à sens simple et à double voie, ainsi qu’à des mesures connexes, telles que la variation de délai et le débit du canal. Cette capacité de mesure offre aux fournisseurs de services une visibilité accrue sur les caractéristiques de performance de leurs réseaux, ce qui facilite la planification, le dépannage et l’évaluation des performances réseau.

Définition des pertes de paquets, des délais et du débit

Dans les réseaux de paquets, la perte de paquets et les délais sont deux des mesures les plus fondamentales en terme de performances.

  • Loss—La perte de paquets est la défaillance d’un ou plusieurs paquets transmis pour arriver à leur destination. La perte de paquets fait référence aux paquets de données abandonnés par le réseau pour gérer la congestion.

    Les applications de données sont très tolérantes aux pertes de paquets, car elles ne sont généralement pas sensibles à l’heure et peuvent retransmettre les paquets qui ont été abandonnés. Cependant, dans les environnements de visioconférence et les communications audio pures, telles que la VoIP, la perte de paquets peut créer de la gigue.

  • Delay—Le délai de paquets (également appelé latence) est le temps de transmission d’un paquet de données d’un point désigné à un autre, en fonction de la vitesse du support de transmission (câble en cuivre, fibre optique ou ondes radio, par exemple) et des délais de transmission par les équipements en chemin, tels que les routeurs et les modems.

    Une faible latence indique une haute efficacité du réseau.

  • Throughput—Le délai de paquet mesure la durée entre le début d’une action et sa réussite, tandis que le débit est le nombre total de ces actions qui se produisent en un temps donné.

Mécanismes de mesure des pertes de paquets et des délais

Les retards et pertes de paquets sont deux mesures fondamentales des performances du réseau. Junos OS fournit un mécanisme à la demande permettant de mesurer la perte de paquets et les délais associés par rapport aux chemins de commutation d’étiquettes (LSP) du MPLS de sauts directs associés (UHP).

Le mécanisme de mesure des pertes de paquets et du délai à la demande est lancé à l’aide CLI commandes suivantes:

  • monitor mpls loss rsvp— Effectue une mesure des pertes à la demande pour les LSP bidirectionnels associés.

  • monitor mpls delay rsvp— Effectue une mesure de délai à la demande pour les LSP BIdirectionnels associés.

  • monitor mpls loss-delay rsvp— Effectue une mesure combinée des pertes et des délais à la demande pour les LSP bidirectionnels associés.

Pour lancer le mécanisme de mesure des retards et des pertes de paquets, vous devez entrer les paramètres de mesure souhaités, tels que le type de mesure et le nom de LSP. À la réception des paramètres, un récapitulatif des données de surveillance des performances est affiché et le mécanisme est terminé.

Mesures de perte de paquets et de délai

Les mesures de performances suivantes sont mesurés à l’aide de mécanismes de perte de paquets et de retard à la demande:

  • Mesure de perte (paquet et octet)

  • Mesure du débit (paquet et octet)

  • Délai de canal à double sens

  • Temps d’aller-retour

  • Variation de délai entre paquets (IPDV)

La commande effectue les mesures de perte et de débit, et la commande exécute le délai de canal à double direction, le délai d’aller-retour et les mesures monitor mpls loss rsvpmonitor mpls delay rsvp IPDV. La commande effectue des mesures combinées de perte et de délai et mesure toutes les mesures de monitor mpls loss-delay rsvp performances mentionnées ci-dessus simultanément.

Concepts de mesure des pertes de paquets et des délais

Les concepts suivants permettent de mieux comprendre les fonctionnalités des pertes de paquets et des délais:

  • Querier— Le routeur PE (Provider Edge) à l’origine du message de requête pour la mesure des pertes ou des délais est à l’origine de la requête.

  • Responder—Un répondeur est le routeur PE de sortie, qui reçoit et répond aux messages de requêtes d’un sécheur.

  • Associated bidirectional LSP— Un LSP bidirectionnel associé se compose de deux LSP unidirectionnels qui sont associés (ou associés les uns aux autres) par le biais d’une configuration sur les deux points de extrémité LSP.

    Seules les LSP bidirectionnelles et bidirectionnelles associées peuvent effectuer les mesures de perte et de délai à la demande.

  • Generic associated channel (G-Ach)— Messages de surveillance des performances pour le flux de mesures à la demande de perte et de délai sur MPLS G-Ach. Ce type de canal ne prend en charge que les réponses en bande et ne prend pas en charge les modes hors bande ou sans réponse.

  • Measurement point (MP)—Le mp est l’emplacement à partir duquel une condition est décrite pour la mesure.

    Le mp pour la perte de paquets du côté de l’émission se trouve entre la structure de commutation et l’interface d’émission. La valeur ajoutée estampillée dans le message de mesure des pertes du matériel avant qu’elle ne soit mise en file d’attente pour transmission.

    Le mp pour la perte de paquets du côté de réception se trouve entre l’interface de réception et la structure de commutation. Le MP est distribué du côté de réception. De plus, lorsque l’interface d’émission est une interface agrégée, le MP est également distribué.

  • Query rate—Le taux de requêtes est l’intervalle entre deux requêtes envoyées pour la mesure des pertes et des délais.

    Les messages de mesure de perte et de délai proviennent du moteur de routage, ce qui fait qu’un taux élevé de requêtes pour plusieurs canaux pèse lourdement sur la moteur de routage. L’intervalle de requêtes minimum pris en charge est de 1 seconde.

    Le taux de requêtes doit être élevé pour les compteurs à 32 bits, car ces compteurs peuvent s’emballer rapidement lorsque le trafic de données est très élevé. Le taux de requêtes peut être faible lorsque des compteurs de 64 bits sont utilisés aux quatre emplacements de mesure impliqués dans la mesure des pertes. Junos OS 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 des pertes de paquets par catégorie de trafic, où il faut créer des compteurs qui conservent les statistiques sur le trafic par classe de trafic.

    Par défaut, les compteurs par classe de trafic ne sont pas créés. Pour configurer la mesure des pertes étendues de trafic, inclure traffic-class-statistics l’instruction au niveau de la [edit protocols mpls statistics] hiérarchie.

    Une fois configurés, les paquets de contrôle qui circulent sur l’ach G ne sont pas comptabilisés dans l’émission et ne reçoivent traffic-class-statistics pas de compteurs.

    Remarque :

    L’activation et la désactivation des statistiques de la classe de trafic entraînent la réinitialisation de tous les compteurs (compteurs agrégés et compteurs par classe de trafic) 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 différé.

    La mesure des pertes directes nécessite de conserver les statistiques de trafic au niveau du trafic à 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 MPC, des compteurs sont créés par défaut au niveau de l’entrée de tous les types de LSP et de sortie des LSP UHP.

    Toutefois, le mode direct de mesure des pertes n’est pas entièrement précis pour les raisons suivantes:

    • Nature parallèle du matériel.

    • La présence de chemins multi-chemins à coût égal (ECMP) dans le réseau, telles que les interfaces Ethernet agrégées, ce qui peut entraîner le re-classement 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 comptabilisés au niveau de l’entrée LSP, mais comptabilisés au sortie du LSP.

    • Le re-commande du trafic de données par rapport au message de mesure des pertes lorsqu’un Diffserv est implémenté dans le réseau MPLS et que la portée de mesure des pertes constitue le canal complet et non le champ d’application de la classe de trafic.

      Pour surmonter cette limitation, effectuez des mesures des pertes de trafic dans la mesure où elles sont étendues lors de l’implémentation d’un Diffserv.

    Remarque :

    La mesure de perte de mode direct est vulnérable aux perturbations lorsque l’interface d’entrée ou de sortie associée aux modifications du LSP.

  • Loss measurement synchronization—Les conditions de synchronisation spécifiées dans la section 2.9.8 du RFC 6374 ne sont pas réelles au sens absolu. Cependant, les compteurs de mesure des pertes étant estampillés dans le matériel, les erreurs introduites pour ne pas répondre aux conditions de synchronisation sont relativement petites. Ces erreurs doivent être quantifiées.

    Lorsque l’interface d’émission ou de réception du LSP est une interface agrégée, plus d’erreurs sont introduites par rapport aux interfaces non agrégées. Dans tous les cas, les compteurs de mesure des pertes sont horodatés sur le matériel et l’erreur doit être quantifiée.

  • Delay measurement accuracy—Lorsque les interfaces d’émission et de réception se trouvent sur différents moteurs de transmission de paquets, l’horloge doit être synchronisée sur ces moteurs de transmission de paquets pour effectuer des mesures de délai dans les deux sens. Cette condition s’applique à la plate-forme sur laquelle est implémentée la fonctionnalité de mesure de délai à la demande.

    Lorsqu’il existe des interfaces agrégées ou ECMP, le délai est mesuré pour un seul des chemins potentiels.

    Lorsqu’un message de perte et de retard est utilisé pour le calcul des délais, la précision du délai est inférieure par rapport à l’utilisation du message de mesure du délai dans certains cas, par exemple lorsque l’interface d’émission ou de réception est une interface agrégée.

    Les mesures de délai sont toujours effectuées par classe de trafic, et la précision de ces mesures doit être quantifiée après les tests.

  • Timestamp format—Junos OS prend en charge uniquement le format IEEE PTP (Precision Time Protocol) 1588 [IEEE1588] pour l’enregistrement des messages de mesure de retard. Le format NTP (Network Time Format) n’est pas pris en charge.

  • Operations, administration, and maintenance (OAM)—Pour indiquer que l’ensemble des messages OAM de MPLS LSP circulent sur l’accès G-Ach de MPLS, et pour que les messages de surveillance des performances MPLS soient transportés sur l’ensemble des messages G-Ach MPLS, l’instruction doit être incluse au niveau de la oam mpls-tp-mode[edit protocols mpls label-switched-path lsp-name] hiérarchie.

Fonctionnalité de mesure des pertes de paquets et des délais de mesure

Figure 1 illustre les méthodes de base utilisées pour la mesure bidirectionnelle des pertes de paquets et des délais. Il existe un canal bidirectionnel 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 à un fonctionnement de mesure au niveau du routeur A. L’opération consiste à envoyer un message de requête au routeur B et au routeur B pour envoyer une réponse. Chaque point de référence indique l’heure à laquelle la requête ou le message de réponse est transmis ou reçu par le canal.

Figure 1 : Mesure bidirectionnelle de baseMesure bidirectionnelle de base

Dans , le routeur A peut s’organiser pour mesurer la perte de paquets sur le canal dans les directions en avant et en arrière-plan, en envoyant des messages de mesure des pertes au Figure 1 routeur B. Chacun des messages aller/retour 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 appendées au message et le message est reflété vers le routeur A. Les deux valeurs sont le nombre de paquets reçus avant l’heure T2 sur le canal depuis le routeur A (B_RxP) et le nombre de paquets transmis avant l’heure T3 sur le canal 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 valeurs compteurs (A_TxP), (B_RxP), (B_TxP) et (A_RxP) permettent au routeur A de calculer les statistiques sur les pertes souhaitées. Le nombre d’émission 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. Pour limiter les effets de l’ent risque, la perte se calcule 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 routeur A comme suit:

  1. A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])

  2. A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])

L’arithmétique fait de la taille du compteur.

Pour mesurer au niveau du routeur A le délai entre le canal et le routeur B, un message d’interrogation de mesure est envoyé du routeur A au routeur B, contenant une session d’enregistrement de l’instant à laquelle il est transmis. Dans Figure 1 , l’ampamp est enregistrée en T1.

Lorsque le message atteint le routeur B, une session d’heure est ajoutée pour enregistrer l’instant où il est reçu (T2). Le message peut désormais être reflété depuis le routeur B vers le routeur A, le routeur B ajoutant sonamp de transmission (T3) et le routeur A en ajoutant son accès de réception (T4).

Ces quatretamps (T1, T2, T3 et T4) permettent au routeur A de calculer le délai à sens simple dans chaque direction, ainsi que le délai à double sens pour le canal. Pour que les calculs soient à sens simple, il est nécessaire de synchroniser les horloges des routeurs A et B.

À ce stade, le routeur A calcule le délai de canal à double direction et le délai d’aller-retour associés au canal comme suit:

  1. Délai de canal à double sens = (T4 - T1) - (T3 - T2)

  2. Temps d’aller-retour = T4 - T1

Fonctionnalités de perte de paquets et de délai

Supported Features of Packet Loss and Delay

Junos OS prend en charge les fonctionnalités suivantes avec des mesures à la demande des pertes et des délais:

  • Surveillance des performances pour les MPLS directs point à point associés LSP uniquement

  • Mesure des pertes

  • Mesure du débit

  • Mesure des délais à double sens (délai du canal et aller-retour)

  • Variation de délai entre paquets (IPDV)

  • Mesure des pertes en mode direct

  • Interfaces SONET agrégées et Ethernet agrégées

  • Prise en charge multichèse

  • Compatible 64 bits

Unsupported Features of Packet Loss and Delay

Junos OS ne prend pas en charge la fonctionnalité de mesure des pertes et des délais à la demande suivante:

  • Mesure de perte et de délai pour les pseudowires (section 2.9.1 sur RFC 6374)

  • Mesure unidirectionnelle (section 2.6 du RFC 6374)

  • Mesure Dyadic (section 2.7 de RFC 6374)

  • Mesure des pertes et des délais en mode loopback (section 2.8 du RFC 6374)

  • Mesure de perte et de délai à un nœud intermédiaire à partir d’un point de terminaison LSP (section 2.9.5 sur RFC 6374)

  • Post-traitement externe (section 2.9.7 de RFC 6374)

  • Mesure des pertes en mode différé (section 2.9.8 sur RFC 6374)

  • Mode pro-actif

  • Systèmes logiques

  • SNMP

Exemple: Configuration des mesures de perte et de délai à la demande

Cet exemple montre comment effectuer des mesures de perte et de délai à la demande pour les chemins de commutation d’étiquettes (LSP) du saut final 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 MX Series de Plates-formes de routage universelles 5G contenant des MPC/MPC uniquement

  • Junos OS version 14.2 ou ultérieure s’exécutant sur tous les routeurs

Avant de commencer:

  1. Configurez les interfaces de l’équipement.

  2. Configurez les numéros de système et les ID de routeur autonomes pour les équipements.

  3. Configurez les protocoles suivants:

    • RSVP

    • MPLS

    • OSPF

Présentation

À partir de Junos OS version 14.2, un outil à la demande de surveillance et de mesure des pertes de paquets, des délais de paquets, ou les deux pour les chemins de commutation d’étiquettes (LSP) point-to-point du MPLS ultimate hop popping associé, est mis en place. L’outil peut être activé à l’aide CLI commandes de base suivantes monitor mpls loss rsvp , monitor mpls delay rsvp et monitor mpls loss-delay rsvp .

Ces commandes fournissent un récapitulatif à la demande des mesures de performance relatives à la perte de paquets en mode direct, aux délais de paquets à double direction, ainsi que des mesures connexes, telles que la variation de délai entre paquets et la mesure du débit du canal.

Cette fonctionnalité fournit une visibilité en temps réel des performances du réseau, ce qui facilite la planification, le dépannage et l’évaluation des performances réseau.

Topologie

Figure 2 illustre les mesures de perte et de délai à la demande grâce à une simple topologie de deux routeurs.

Figure 2 : Configuration des mesures de perte et de délai à la demandeConfiguration des mesures de perte et de délai à la demande

Dans cet exemple, un LSP bidirectionnel associé est configuré entre les routeurs R1 et R2, pour lesquels les mesures de performance sont mesurées.

Configuration

CLI configuration rapide

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, copiez et collez les commandes dans le CLI au niveau de la hiérarchie, puis entrez dans le [edit]commit mode de configuration.

R1

R2

Procédure

Procédure étape par étape

L’exemple suivant nécessite de naviguer dans différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation du CLI, consultez le guide de l’CLI en mode de configuration dans CLI’utilisateur.

Pour configurer le routeur R1:

  1. Activez le châssis avec des services de tunnel et une configuration améliorée des services de réseau IP.

  2. Configurez les interfaces du routeur R1.

  3. Configurez l’ID du routeur pour le routeur R1.

  4. Activer RSVP sur toutes les interfaces du routeur R1, à l’exception de l’interface de gestion.

  5. Activer MPLS sur toutes les interfaces du routeur R1, à l’exception de l’interface de gestion.

  6. Configurez un LSP bidirectionnel associé vers le routeur R2.

  7. Créez des classes de trafic pour la maintenance des statistiques de trafic de données par classe de trafic.

    Cela permet de mesurer les pertes de trafic dans la mesure du champ d’application.

  8. Configurez OSPF avec des capacités d’ingénierie du trafic et activez OSPF sur toutes les interfaces du routeur R1, à l’exception de l’interface de gestion.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les show chassis commandes et le , et show interfacesshow routing-optionsshow protocols le Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Vérification

Vérifier que la configuration fonctionne correctement.

Vérification du statut de LSP

But

Vérifiez que le LSP bidirectionnel associé entre les routeurs R1 et R2 est en place.

Action

À partir du mode opérationnel, exécutez show mpls lsp la commande.

Sens

Le LSP bidirectionnel R1-R2 bidirectionnel est actif.

Vérification de la mesure des pertes de paquets

But

Vérifier les résultats des pertes à la demande.

Action

À partir du mode opérationnel, exécutez monitor mpls loss rsvp R1-R2 count 2 detail la commande.

Sens

La mesure de la perte de paquets pour deux nombres est affichée.

Vérification de la mesure du délai de paquet

But

Vérifier les résultats des mesures de délai à la demande.

Action

À partir du mode opérationnel, exécutez monitor mpls delay rsvp R1-R2 count 2 detail la commande.

Sens

La mesure du délai de paquet pour deux nombres est affichée.

Vérification de la mesure du délai de perte de paquet

But

Vérifier les résultats des mesures de perte et de délai à la demande.

Action

À partir du mode opérationnel, exécutez monitor mpls loss-delay rsvp R1-R2 count 2 detail la commande.

Sens

La perte de paquets et la mesure de délai pour deux nombres sont affichées.

Exemple: Configuration des mesures de perte et de délai actives pour les MPLS LSP bidirectionnels

Cet exemple montre comment configurer des mesures de perte et de délai pro-actives pour des chemins de commutation d’étiquettes (LSP) à saut final 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 MX Series de Plates-formes de routage universelles 5G contenant des MPC/MPC uniquement

  • Junos OS version 15.1 ou ultérieure s’exécutant sur tous les routeurs

Avant de commencer:

  1. Configurez les interfaces de l’équipement.

  2. Configurez les numéros de système et les ID de routeur autonomes pour les équipements.

  3. Configurez les protocoles suivants:

    1. MPLS

    2. OSPF

    3. RSVP

Présentation

À partir de Junos OS version 15.1, un outil pro-actif de surveillance et de mesure de la perte de paquets, des délais de paquets ou des deux pour les chemins de commutation d’étiquettes (LSP) de saut ultime vers le saut MPLS est mis en place.

Cette fonctionnalité fournit les mesures de performances suivantes:

  • Variation de délai entre paquets (IPDV)

  • Mesure des pertes

  • RtT (Round-Trip Delay)

  • Mesure du débit

  • Délai de canal à double sens

Cette fonctionnalité fournit une visibilité en temps réel des performances du réseau, ce qui facilite la planification, le dépannage et l’évaluation des performances réseau.

Topologie

Figure 3 illustre les mesures de perte et de délai pro-actives à l’aide d’une simple topologie de deux routeurs.

Figure 3 : Configuration des mesures de perte et de délai pro-activesConfiguration des mesures de perte et de délai pro-actives

Dans cet exemple, un LSP bidirectionnel associé est configuré entre les routeurs R1 et R2, pour lesquels les mesures de performance sont mesurées.

Configuration

CLI configuration rapide

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, copiez et collez les commandes dans le CLI au niveau de la hiérarchie, puis entrez dans le [edit]commit mode de configuration.

R1

R2

Procédure

Procédure étape par étape

L’exemple suivant nécessite de naviguer dans différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation du CLI, consultez le guide de l’CLI en mode de configuration dans CLI’utilisateur.

Pour configurer le routeur R1:

  1. Activez la configuration des services réseau IP améliorés.

  2. Configurez les interfaces du routeur R1.

  3. Configurez l’ID du routeur pour le routeur R1.

  4. Activer RSVP sur toutes les interfaces du routeur R1, à l’exception de l’interface de gestion.

  5. Activer MPLS sur toutes les interfaces du routeur R1, à l’exception de l’interface de gestion.

  6. Configurez un LSP bidirectionnel associé vers le routeur R2.

  7. Créez des classes de trafic pour la maintenance des statistiques de trafic de données par classe de trafic.

    Cela permet de mesurer les pertes de trafic à grande échelle et de mesurer les délais.

  8. Configurez la surveillance des performances du côté plus sec.

  9. Configurez la surveillance des performances du côté du répondeur.

  10. Configurez OSPF avec des capacités d’ingénierie du trafic et activez OSPF sur toutes les interfaces du routeur R1, à l’exception de l’interface de gestion.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les show chassis commandes et le , et show interfacesshow routing-optionsshow protocols le Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Vérification

Vérification des pertes et mesures des retards

But

Vérifier la mesure des pertes et des délais.

Action

À partir du mode opérationnel, exécutez show performance-monitoring mpls lsp la commande.

Sens

Les mesures de perte de paquet et de mesure de retard pour LSP sont affichées.

Configuration des mesures de perte et de délai à la demande

Vous pouvez configurer une mesure de perte et de délai à la demande pour les chemins de commutation d’étiquettes (LSP) « point-to-point » (UHP) dans les réseaux MPLS afin de surveiller les performances du réseau. Les commandes , et les commandes CLI fournissent un récapitulatif des performances relatives à la perte de paquets en mode direct, au délai dans les deux sens, ainsi qu’à des mesures connexes, telles que la variation de délai entre paquets et la mesure du débit du monitor mpls loss rsvpmonitor mpls delay rsvpmonitor mpls loss-delay rsvp canal.

Cette fonctionnalité fournit une visibilité en temps réel des performances du réseau, ce qui facilite la planification, le dépannage et l’évaluation des performances réseau.

Avant de commencer:

  1. Configurez les interfaces de l’équipement.

  2. Configurez l’ID du routeur d’équipement.

  3. Configurez les protocoles suivants:

    • RSVP

    • OSPF

      Activer des fonctionnalités d’ingénierie de trafic.

    • MPLS

Pour configurer l’équipement PE:

  1. Activez le châssis avec des services de tunnel et une configuration améliorée des services de réseau IP.
  2. Configurez un LSP bidirectionnel associé au routeur distant.
  3. Créez des classes de trafic pour la maintenance des statistiques de trafic de données par classe de trafic.

    Cela permet de mesurer les pertes de trafic dans la mesure du champ d’application.

Configuration des mesures de perte et de délai pro-actives

Vous pouvez configurer des mesures de perte et de délai pro-actives pour des chemins de commutation d’étiquettes (LSP) « point-to-point » vers saut final dans des réseaux MPLS afin de surveiller les performances du réseau. La commande CLI fournit un récapitulatif des mesures de performance relatives à la perte de paquets en mode direct, au délai de paquet à double voie, ainsi que des mesures connexes, telles que la variation de délai entre paquets et la mesure du débit du show performance-monitoring mpls lsp canal.

Cette fonctionnalité fournit une visibilité en temps réel des performances du réseau, ce qui facilite la planification, le dépannage et l’évaluation des performances réseau.

Cette fonctionnalité fournit les mesures de performances suivantes:

  • Variation de délai entre paquets (IPDV)

  • Mesure des pertes

  • RtT (Round-Trip Delay)

  • Mesure du débit

  • Délai de canal à double sens

Avant de commencer:

  1. Configurez les interfaces de l’équipement.

  2. Configurez les numéros de système et les ID de routeur autonomes pour les équipements.

  3. Configurez les protocoles suivants:

    • MPLS

    • OSPF

    • RSVP

Pour configurer les mesures de perte et de délai pro-actives sur l’équipement PE:

  1. Configurez un LSP bidirectionnel associé vers le routeur R2.
  2. Créez des classes de trafic pour la maintenance des statistiques de trafic de données par classe de trafic.

    Cela permet de mesurer les pertes de trafic et les retards.

  3. Configurez la surveillance des performances du côté plus sec.
  4. Configurez la surveillance des performances du côté du répondeur.