Présentation de l’OAM du service Ethernet ITU-T Y.1731
SUMMARY Cette section décrit le service OAM (ITU-TY.1731) et ses deux composants principaux : gestion des pannes (surveillance, détection et isolation) et surveillance des performances (mesure de la perte de trame, mesure synthétique de la perte de trame et mesure du délai de trame).
Vue d’ensemble des mesures des retards de trame Ethernet
- Fonctionnalité ITU-T Y.1731 de mesure du délai de trame
- Mesure du délai de trame Ethernet à sens unique
- Mesure bidirectionnaire du délai de trame Ethernet
- Choisir entre un et deux sens de l’ETH-DM
- Restrictions relatives à la mesure des retards de trame Ethernet
Fonctionnalité ITU-T Y.1731 de mesure du délai de trame
La norme IEEE 802.3-2005 pour les opérations, l’administration et la maintenance Ethernet (OAM) définit un ensemble de mécanismes de gestion des pannes de liaison permettant de détecter et de signaler les pannes de liaison sur un seul lan Ethernet point à point.
Junos OS prend en charge les normes OAM clés qui permettent une gestion et une surveillance automatisées de bout en bout du service Ethernet par les fournisseurs de services :
Norme IEEE 802.1ag, également connue sous le nom de « Connectivity Fault Management (CFM) ».
Recommandation UIT-T Y.1731, qui utilise une terminologie différente de la norme IEEE 802.1ag et définit les fonctionnalités OAM de service Ethernet pour la surveillance des pannes, les diagnostics et la surveillance des performances.
Ces fonctionnalités permettent aux opérateurs d’offrir des accords de niveau de service (SLA) contraignants et de générer de nouveaux revenus grâce à des packages de services garantis à des taux et des performances adaptés aux besoins spécifiques de leurs clients.
Les routeurs ACX Series prennent en charge des modes proactifs et à la demande.
Les routeurs ACX5048 et ACX5096 ne prennent en charge que l’horodatage logiciel pour mesurer les retards.
Ethernet CFM
La norme IEEE 802.1ag pour la gestion des pannes de connectivité (CFM) définit des mécanismes permettant d’assurer le service Ethernet de bout en bout sur n’importe quel chemin, qu’il s’agisse d’une liaison unique ou de plusieurs liaisons couvrant des réseaux composés de plusieurs LAN.
Pour les interfaces Ethernet sur les routeurs M320, MX Series et T Series, Junos OS prend en charge les éléments clés de la norme Ethernet CFM suivants :
Surveillance des pannes à l’aide du protocole IEEE 802.1ag Ethernet OAM Continuity Check
Détection des chemins et vérification des pannes à l’aide du protocole Ethernet OAM Linktrace IEEE 802.1ag
Isolation des pannes à l’aide du protocole ieee 802.1ag de bouclage OAM Ethernet
Dans un environnement CFM, les entités réseau telles que les opérateurs réseau, les fournisseurs de services et les clients peuvent faire partie de différents domaines administratifs. Chaque domaine administratif est mappé en un seul domaine de maintenance. Les domaines de maintenance sont configurés avec des valeurs de niveau différentes pour les séparer. Chaque domaine fournit suffisamment d’informations pour permettre aux entités d’effectuer leur propre gestion et surveillance de bout en bout, tout en évitant tout compromission de sécurité.
Figure 1 affiche les relations entre les ponts Ethernet du client, du fournisseur et de l’opérateur, les domaines de maintenance, les points de fin d’association de maintenance (MEP) et les points intermédiaires de maintenance (MIP).
Sur les routeurs ACX Series, les points intermédiaires de maintenance (MIP) sont pris en charge uniquement sur les routeurs ACX5048 et ACX5096.
Mesure du délai de trame Ethernet
Deux objectifs clés de la fonctionnalité OAM sont de mesurer les attributs de qualité de service tels que le délai de trame et la variation du délai de trame (également appelé « gigue de trame »). Ces mesures peuvent vous permettre d’identifier les problèmes de réseau avant que les clients ne soient touchés par des défauts réseau.
Junos OS prend en charge la mesure des délais de trame Ethernet entre les MEP configurés sur des interfaces physiques ou logiques Ethernet sur les routeurs MX Series. La mesure du délai de trame Ethernet permet aux opérateurs de contrôler finement le déclenchement de la mesure des retards sur un service donné et peut être utilisée pour surveiller les SLA. La mesure du délai de trame Ethernet collecte également d’autres informations utiles, telles que les retards de cas les plus mauvais et les meilleurs, le délai moyen et la variation des retards moyens. L’implémentation junos OS de la mesure du délai de trame Ethernet (ETH-DM) est entièrement conforme à la Recommandation UIT-T Y.1731, Fonctions et mécanismes OAM pour les réseaux ethernet. La recommandation définit les mécanismes OAM pour l’exploitation et la maintenance du réseau au niveau de la couche de service Ethernet, appelée « couche ETH » dans la terminologie de l’UIT-T.
Les routeurs MX Series avec concentrateurs de ports modulaires (MPC) et les MPC 10 Gigabit Ethernet avec SFP+ prennent en charge la fonctionnalité ITU-T Y.1731 sur VPLS pour les retards de trame et les variations de retard.
Le Mx Series Virtual Chassis ne prend pas en charge la mesure du délai de trame Ethernet (DM).
Mesure du délai de trame Ethernet à sens unique
Dans le mode ETH-DM à sens unique, une série de valeurs de délai de trame et de variation du délai de trame sont calculées en fonction du temps écoulé entre le moment où une trame de mesure est envoyée par le MEP à l’origine sur un routeur et l’heure à laquelle la trame est reçue au niveau du récepteur MEP sur l’autre routeur.
Les routeurs ACX Series ne prennent pas en charge la mesure de délai de trame Ethernet unidirectionnaire.
- Transmission 1DM
- Réception 1DM
- Statistiques de l’ETH-DM à sens unique
- Nombre de trames ETH-DM à sens unique
- Synchronisation des horloges système
Transmission 1DM
Lorsque vous commencez une mesure de retard de trame à sens unique, le routeur envoie des trames 1DM (trames qui transportent l’unité de données de protocole (PDU) pour une mesure de retard à sens unique, du MEP initiant au MEP récepteur au débit et au nombre de trames que vous spécifiez. Le routeur marque chaque trame 1DM comme étant inéligible et insère un horodatage du temps de transmission dans la trame.
Réception 1DM
Lorsqu’un MEP reçoit une trame 1DM, le routeur qui contient le MEP récepteur mesure le délai à sens unique pour cette trame (la différence entre le temps de réception de la trame et l’horodatage contenu dans la trame elle-même) et la variation de retard (la différence entre les valeurs de retard actuelles et précédentes).
Statistiques de l’ETH-DM à sens unique
Le routeur qui contient le récepteur MEP stocke chaque ensemble de statistiques de retard à sens unique dans la base de données ETH-DM. La base de données ETH-DM collecte jusqu’à 100 ensembles de statistiques pour chaque session CFM donnée (paire de pairs MEP). Vous pouvez accéder à ces statistiques à tout moment en affichant le contenu de la base de données ETH-DM.
Nombre de trames ETH-DM à sens unique
Chaque routeur compte le nombre de trames ETH-DM à sens unique envoyées et reçues :
Pour un MEP initiant, le routeur compte le nombre de trames 1DM envoyées.
Pour un meP récepteur, le routeur compte le nombre de trames 1DM valides reçues et le nombre de trames 1DM non valides reçues.
Chaque routeur stocke le nombre de trames ETH-DM dans la base de données CFM. La base de données CFM stocke les statistiques des sessions CFM et, pour les interfaces qui prennent en charge l’ETH-DM, le nombre de trames ETH-DM. Vous pouvez accéder aux nombres de trames à tout moment en affichant les informations de la base de données CFM pour les interfaces Ethernet attribuées aux députés MEP ou pour les MEP dans les sessions CFM.
Synchronisation des horloges système
L’exactitude des calculs de retard à sens unique dépend de la synchronisation étroite des horloges système au niveau du MEP initiant et du meP récepteur.
La précision de la variation des retards à sens unique ne dépend pas de la synchronisation de l’horloge système. Étant donné que la variation de délai est simplement la différence entre les valeurs de retard à sens unique consécutives, la période hors phase est éliminée des valeurs de gigue de trame.
Pour une mesure de délai de trame Ethernet unidirectionnaire donnée, les valeurs de délai de trame et de variation de délai de trame sont disponibles uniquement sur le routeur qui contient le meP du récepteur.
Mesure bidirectionnaire du délai de trame Ethernet
En mode ETH-DM à double sens, les valeurs de délai de trame et de variation du délai de trame sont basées sur la différence de temps entre le moment où le MEP initateur transmet une trame de requête et reçoit une trame de réponse du meP répondeur, en soustrayant le temps écoulé au meP répondeur.
- DMM Transmission
- DMR Transmission
- Réception DMR
- Statistiques etH-DM bidirectionnaires
- Nombre de trames ETH-DM bidirectionnaires
DMM Transmission
Lorsque vous commencez une mesure de retard de trame à deux sens, le routeur envoie des trames de message de mesure de retard (DMM), des trames qui transportent le PDU pour une demande ETH-DM bidirectionnaire, du MEP initiant au meP répondeur au débit et au nombre de trames que vous spécifiez. Le routeur marque chaque trame DMM comme étant inéligible et insère un horodatage du temps de transmission dans la trame.
DMR Transmission
Lorsqu’un MEP reçoit une trame DMM, le meP répond avec une trame de réponse de mesure du délai (DMR), qui transporte les informations de réponse ETH-DM et une copie de l’horodatage contenu dans la trame DMM.
Réception DMR
Lorsqu’un MEP reçoit un DMR valide, le routeur qui contient le MEP mesure le délai à double sens pour cette trame en fonction de la séquence d’horodatage suivante :
TI TxDMM
TRRxDMM
TRTxDMR
TIRxDMR
Un délai de trame à double sens est calculé comme suit :
[TIRxDMR – TITxDMM] – [TRTxDMR – TRRxDMM]
Le calcul montre que le délai de trame correspond à la différence entre le moment où le meP initateur envoie une trame DMM et le moment auquel le meP initiant reçoit la trame DMR associée de l’intervenant meP, moins le temps écoulé au meP répondeur.
La variation de délai est la différence entre les valeurs de retard actuelles et précédentes.
Statistiques etH-DM bidirectionnaires
Le routeur qui contient l’initiative MEP stocke chaque ensemble de statistiques de retard à double sens dans la base de données ETH-DM. La base de données ETH-DM collecte jusqu’à 100 ensembles de statistiques pour chaque session CFM donnée (paire de pairs MEP). Vous pouvez accéder à ces statistiques à tout moment en affichant le contenu de la base de données ETH-DM.
Nombre de trames ETH-DM bidirectionnaires
Chaque routeur compte le nombre de trames ETH-DM à double sens envoyées et reçues :
Pour un MEP initiant, le routeur compte le nombre de trames DMM transmises, le nombre de trames DMR valides reçues et le nombre de trames DMR non valides reçues.
Pour un meP répondeur, le routeur compte le nombre de trames DMR envoyées.
Chaque routeur stocke le nombre de trames ETH-DM dans la base de données CFM. La base de données CFM stocke les statistiques des sessions CFM et, pour les interfaces qui prennent en charge l’ETH-DM, le nombre de trames ETH-DM. Vous pouvez accéder aux nombres de trames à tout moment en affichant les informations de la base de données CFM pour les interfaces Ethernet attribuées aux députés MEP ou pour les MEP dans les sessions CFM.
Pour une mesure de délai de trame Ethernet bidirectionnaire donnée, les valeurs de délai de trame et de variation de délai de trame sont disponibles uniquement au niveau du routeur qui contient le MEP initiatique.
Choisir entre un et deux sens de l’ETH-DM
La mesure du délai de trame à sens unique nécessite que les horloges système au niveau du MEP et du récepteur MEP soient étroitement synchronisées. La mesure du délai de trame dans les deux sens ne nécessite pas de synchronisation des deux systèmes. S’il n’est pas pratique de synchroniser les horloges, les mesures de retard de trame à double sens sont plus précises.
Lorsque deux systèmes sont physiquement proches l’un de l’autre, leurs valeurs de retard à sens unique sont très élevées par rapport à leurs valeurs de délai bidirectionnels. Pour mesurer les retards à sens unique, les deux systèmes doivent être synchronisés à un niveau très granulaire, et les routeurs MX Series ne prennent pas actuellement en charge cette synchronisation granulaire.
Restrictions relatives à la mesure des retards de trame Ethernet
Les restrictions suivantes s’appliquent à la fonctionnalité de mesure du délai de trame Ethernet :
La fonctionnalité ETH-DM n’est pas prise en charge sur les pseudowires de commutation d’étiquettes (LSI).
La fonctionnalité ETH-DM est prise en charge sur les interfaces Ethernet agrégées.
L’horodatage assisté par le matériel pour les trames ETH-DM dans le chemin de réception n’est pris en charge que pour les interfaces MEP sur les DPC améliorés et les DPC de file d’attente améliorée dans les routeurs MX Series. Pour plus d’informations sur l’horodatage assisté par le matériel, consultez les consignes pour configurer les routeurs pour prendre en charge une session ETH-DM et activer l’option d’horodatage assisté par le matériel.
Les mesures de retard des trames Ethernet ne peuvent être déclenchées que lorsque le démon de gestion périodique des paquets distribué (
ppm) est activé. Pour plus d’informations sur cette limitation, consultez consignes de configuration des routeurs pour prendre en charge une session ETH-DM et s’assurer que les ppm distribués ne sont pas désactivés.Vous ne pouvez surveiller qu’une seule session à la fois vers la même adresse MEP ou MAC distante. Pour plus d’informations sur le démarrage d’une session ETH-DM, voir Démarrage d’une session ETH-DM.
Les statistiques etH-DM ne sont collectées que sur l’un des deux routeurs homologues de la session ETH-DM. Pour une session ETH-DM à sens unique, vous pouvez afficher les statistiques ETH-DM au niveau du récepteur MEP uniquement, à l’aide de commandes spécifiques
showà l’ETH-DM. Pour une session ETH-DM à double sens, vous pouvez afficher les statistiques de retard de trame au niveau du MEP de l’instigateur uniquement, à l’aide des mêmes commandes spécifiquesshowà l’ETH-DM. Pour plus d’informations, voir Gestion des statistiques ETH-DM et Nombre de trames ETH-DM.Les nombres de trames etH-DM sont collectés au niveau des deux MEP et sont stockés dans les bases de données CFM respectives.
Si le commutateur GRES ( Graceful Routing Engine Switchover ) se produit, les statistiques ETH-DM collectées sont perdues et le nombre de trames ETH-DM est remis à zéro. Par conséquent, la collecte des statistiques ETH-DM et des compteurs de trames ETH-DM doit être redémarrée une fois le basculement terminé. GRES permet à un routeur doté de deux moteurs de routage de passer d’un moteur de routage principal à un moteur de routage de secours sans interruption du transfert de paquets. Pour plus d’informations, consultez le Guide de l’utilisateur junos OS haute disponibilité.
L’exactitude des statistiques sur les retards de trame est compromise lorsque le système change (par exemple à partir de la reconfiguration). Nous vous recommandons d’effectuer des mesures de délai de trame Ethernet sur un système stable.
Vue d’ensemble de la mesure de la perte de trame Ethernet
Les principaux objectifs de la fonctionnalité OAM sont de mesurer les attributs de qualité de service tels que le délai de trame, la variation du délai de trame (également appelé « gigue de trame ») et la perte de trame. De telles mesures vous permettent d’identifier les problèmes réseau avant que les clients ne soient affectés par des défauts réseau.
Junos OS prend en charge la mesure des pertes de trames Ethernet (ETH-LM) entre les points de terminaison d’association de maintenance (MEP) configurés sur des interfaces physiques ou logiques Ethernet sur les routeurs MX Series et n’est actuellement pris en charge que pour le service VPWS . L’ETH-LM est utilisé par les opérateurs pour collecter des valeurs de compteur applicables aux trames de service entrantes et sortantes. Ces compteurs tiennent un compte de trames de données transmises et reçues entre une paire de députés. La mesure de la perte de trames Ethernet est effectuée en envoyant des trames avec des informations ETH-LM à un MEP pair et en recevant de la même manière des trames avec des informations ETH-LM du MEP pair. Ce type de mesure de perte de trame est également connu sous le nom de mesure de perte Ethernet à fin unique.
Le Virtual Chassis MX Series ne prend pas en charge la mesure de la perte de trame Ethernet (ETH-LM).
L’ETH-LM prend en charge les mesures de perte de trame suivantes :
Mesure de la perte de trame quasi-complète : mesure de la perte d’image associée aux trames de données entrantes.
Mesure de la perte de trames de bout en bout : mesure de la perte de trame associée aux trames de données sortantes.
La fonctionnalité de mesure proactive et double des pertes de l’ITU-T Y1731 n’est pas prise en charge sur les routeurs ACX Series.
La fonctionnalité ETH-LM est prise en charge sur les interfaces Ethernet agrégées.
À partir de la version 16.1 de Junos OS, les résultats de la mesure des pertes Ethernet (ETH-LM) sont inexacts lorsque les PDU de gestion des pannes de connectivité (CFM) et de surveillance des performances (PM) reçus localement à un point de terminaison de maintenance (MEP) classé comme appartenant à la classe jaune ou à une priorité de perte de paquets (PLP) de moyenne à élevée. Ce problème de résultats incorrects est spécifique à la mesure des pertes Ethernet pour les sessions CFM des MEP en panne. Les statistiques de mesure des pertes Ethernet sont inexactes dans les scénarios suivants :
La mesure de perte Ethernet fonctionne sur une session CFM pour un MEP à l’état descendant
Les PDU CFM reçus sur l’interface logique du MEP vers le bas sont classés par le classificateur dans la catégorie PLP jaune ou moyennement élevé
Un paquet est identifié comme jaune lorsque le classificateur d’entrée marque le PLP comme moyen-élevé.
Le problème des écarts avec les résultats de mesure des pertes Ethernet n’est pas observé lorsque vous configurez la mesure de perte Ethernet en mode incolore. Pour éviter ce problème d’imprécision des résultats de mesure des pertes, provisionnez tous les PDU CFM locaux en vert ou avec un PLP aussi élevé.
À partir de la version 16.1 de Junos OS, la surveillance des performances pour la gestion des pannes de connectivité (en incluant l’énoncé performance-monitoring et ses sous-états au niveau de la [edit protocols oam ethernet connectivity-fault-management] hiérarchie) n’est pas prise en charge lorsque l’interface réseau vers réseau (NNI) ou l’interface de sortie est une interface Ethernet agrégée avec des liaisons membres sur des DPC.
Mesure de l’accord de niveau de service
La mesure des accords de niveau de service (SLA) est le processus de surveillance de la bande passante, des retards, des variations de retard (gigue), de la continuité et de la disponibilité d’un service (E-Line ou E-LAN). Il vous permet d’identifier les problèmes de réseau avant que les clients ne soient affectés par des défauts réseau.
Les services Ethernet VPN peuvent être classés en :
Services peer-to-peer (services E-Line) : les services E-Line sont proposés à l’aide d’un service vpn privé virtuel de couche 2 (VPWS) basé sur MPLS.
Services multipoint à multipoint (services E-LAN) : les services E-LAN sont proposés à l’aide d’un service LAN privé virtuel (VPLS) basé sur MPLS.
Pour plus d’informations, consultez le Guide de configuration des VPN Junos.
Dans Junos OS, les mesures sla sont classées en :
Mode à la demande : en mode à la demande, les mesures sont déclenchées via la CLI.
Mode proactif : en mode proactif, les mesures sont déclenchées par une application itératrice.
Notez que la mesure du délai de trame Ethernet et la mesure de la perte de trame Ethernet ne sont pas prises en charge sur l’interface ae .
Mode à la demande pour la mesure des SLA
En mode à la demande, les mesures sont déclenchées par l’utilisateur via la CLI.
Lorsque l’utilisateur déclenche la mesure du retard via l’interface cli, la demande de mesure de retard qui est générée est conformément aux formats de trame spécifiés par la norme ITU-T Y.1731. Pour mesurer les retards dans les deux sens, le traitement côté serveur peut être délégué au moteur de transfert de paquets afin d’éviter toute surcharge sur le moteur de routage. Pour plus d’informations, voir Configuration des routeurs pour prendre en charge une session ETH-DM. Lorsque le traitement côté serveur est délégué au moteur de transfert de paquets, les compteurs de trame de message de mesure de retard (DMM) et les compteurs de trames receivetransmit de mesure de retard (DMR) ne sont pas affichés par la show commande.
Lorsque l’utilisateur déclenche la mesure des pertes via l’interface de ligne de commande, le routeur envoie les paquets au format standard avec la mesure de la perte TLV. Par défaut, l’argument session-id-tlv est inclus dans le paquet pour permettre des sessions de mesure de perte simultanées à partir d’un même MEP local. Vous pouvez également désactiver l’ID de session TLV à l’aide de l’argument no-session-id-tlv .
L’ETH-LM unique est utilisé à la demande à des fins d’exploitation, d’administration et de maintenance. Un meP envoie des trames avec des informations de requête ETH-LM à son pair MEP et reçoit des trames avec les informations de réponse ETH-LM de son pair MEP pour effectuer des mesures de perte. L’unité de données de protocole (PDU) utilisée pour une requête ETH-LM à fin unique est appelée message de mesure de perte (LMM) et le PDU utilisé pour une réponse ETH-LM à fin unique est appelé réponse de mesure de perte (LMR).
Mode proactif pour la mesure des SLA
En mode proactif, les mesures sla sont déclenchées par une application itératrice. Un itérateur est conçu pour transmettre périodiquement des paquets de mesure SLA sous forme de trames conformes à l’UIT-Y.1731 pour mesurer les retards ou les pertes dans les deux sens sur les routeurs MX Series. Ce mode diffère de la mesure des SLA à la demande, à l’initiative de l’utilisateur. L’itérateur envoie périodiquement des paquets de demande de mesure de retard ou de perte pour chacune des connexions qui lui sont enregistrées. Les itérateurs s’assurent que les cycles de mesure ne se produisent pas en même temps pour la même connexion afin d’éviter la surcharge du processeur. Junos OS prend en charge le mode proactif pour VPWS. Pour qu’un itérateur forme une adjacence à distance et devienne fonctionnel, le message de contrôle de la continuité (CCM) doit être actif entre les configurations MEP locales et distantes de la gestion des pannes de connectivité (CFM). Toute modification des paramètres d’adjacence itérateur réinitialise les statistiques de l’itérateur existant et redémarre l’itérateur. Ici, le terme adjacence fait référence à l’association de deux points de terminaison (connectés directement ou virtuellement) avec des informations pertinentes pour la compréhension mutuelle, qui sont utilisées pour le traitement ultérieur. Par exemple, l’adjacence itératrice fait référence à l’association itératrice entre les deux points de terminaison des députés.
Pour chaque DPC ou MPC, seules 30 instances itératrices pour une valeur de cycle de 10 millisecondes (ms) sont prises en charge. Dans Junos OS, 255 configurations de profils itérateurs et 2000 associations MEP distantes sont prises en charge.
Les itérateurs avec une valeur de cycle inférieure à 100 ms ne sont pris en charge que pour les itérateurs infinis, tandis que les itérateurs dont la valeur de cycle est supérieure à 100 ms sont pris en charge à la fois pour les itérateurs finis et infinis. Les itérateurs infinis sont des itérateurs qui s’exécutent à l’infini jusqu’à ce que l’itérateur soit désactivé ou désactivé manuellement.
Les routeurs ACX5048 et ACX5096 prennent en charge un cycle itérateur d’une seconde et plus.
Un service VPWS configuré sur un routeur est surveillé pour les mesures sla en enregistrant la connexion (ici, la connexion est une paire de MEP distants et locaux) sur un itérateur, puis en initiant une transmission périodique de la trame de mesure SLA sur ces connexions. Le service de bout en bout est identifié via un point de fin d’association de maintenance (MEP) configuré aux deux extrémités.
Pour mesurer les retards dans les deux sens et mesurer les pertes, un itérateur envoie un message de demande pour la connexion de la liste (le cas échéant), puis envoie un message de demande pour la connexion interrogée dans l’ancien cycle d’itération. Les messages de demande de dos à dos pour les trames de mesure des SLA et leurs réponses aident à calculer la variation des retards et la mesure des pertes.
La transmission de trames Y.1731 pour un service attaché à un itérateur se poursuit sans fin, à moins qu’un opérateur n’intervienne et ne l’arrête que jusqu’à ce que la condition du nombre d’itérations soit remplie. Pour empêcher l’itérateur d’envoyer des trames de mesure SLA plus proactives, l’opérateur doit effectuer l’une des tâches suivantes :
Activez l’instruction
deactivate sla-iterator-profileau niveau de la[edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance association ma-name mep mep-id remote-mep mep-id]hiérarchie.Provisionnez une
disabledéclaration sous le profil itérateur correspondant au niveau de la[edit protocols oam ethernet connectivity-fault-management performance-monitoring sla-iterator-profiles profile-name]hiérarchie.
Mesure des retards Ethernet et mesure des pertes en mode proactif
Dans le cadre d’une mesure de retard à double sens, la trame de message de mesure du retard (DMM) est déclenchée via une application itératrice. La trame DMM porte un type itérateur, une longueur et une valeur (TLV) en plus des champs décrits dans le format de trame standard et le serveur copie l’itérateur TLV de la trame DMM à la trame de mesure du retard (DMR).
Dans le calcul des variations de retard à sens unique à l’aide de la méthode de mesure du retard à double sens, le calcul de la variation de retard est basé sur les horodatages présents dans la trame DMR (et non la trame 1DM). Par conséquent, il n’est pas nécessaire de synchroniser les horloges côté client et côté serveur. En supposant que la différence dans leurs horloges reste constante, les résultats des variations de retard à sens unique devraient être assez précis. Cette méthode élimine également le besoin d’envoyer des trames 1DM distinctes uniquement pour mesurer les variations de retard à sens unique.
En mode proactif pour la mesure des pertes, le routeur envoie des paquets au format standard avec des mesures de perte TLV et itérateur TLV.
Présentation du protocole de notification de défaillance Ethernet
Le protocole FNP (Failure Notification Protocol) est un mécanisme de notification de défaillance qui détecte les défaillances dans les réseaux de transport Ethernet point à point sur les routeurs MX Series. En cas d’échec d’une liaison de nœud, FNP détecte la défaillance et envoie des messages FNP aux nœuds adjacents qui indiquent qu’un circuit est en panne. Une fois le message FNP reçu, les nœuds peuvent rediriger le trafic vers le circuit de protection.
FNP est pris en charge uniquement sur les services E-Line.
Un service E-Line fournit une connectivité Ethernet point à point sécurisée entre deux interfaces réseau utilisateur (UNIs). Les services E-Line sont un service protégé et chaque service dispose d’un circuit de fonctionnement et d’un circuit de protection. Cfm est utilisé pour surveiller les chemins de travail et protéger les chemins. Les intervalles CCM entraînent un temps de basculement en centaines de millisecondes ou quelques secondes. FNP permet de détecter et de propager les défaillances de circuit de service en moins de 50 ms et d’assurer un basculement de 50 ms pour les services E-Line.
Le routeur MX agit comme un nœud PE et gère les messages FNP reçus sur le VLAN de gestion et les messages FNP reçus sur les interfaces Ethernet et les PW créés pour la gestion VPLS. Les routeurs MX Series ne lancent pas de messages FNP et répondent uniquement aux messages FNP générés par les équipements du réseau d’accès Ethernet. FNP ne peut être activé que sur les interfaces logiques qui font partie d’une instance de routage VPLS, et aucune interface physique dans cette instance de routage VPLS n’a dû être configurée par CCM. FNP ne peut être activé que sur une seule interface logique par interface physique.
Tous les services E-Line sont configurés en tant que circuits de couche 2 avec protection de périphérie. Un VLAN associé au circuit de travail ou au circuit de protection doit être mapé à une interface logique. Aucun port trunk ou port d’accès n’est pris en charge dans la liaison en anneau pour les VLAN utilisés par les services E-LINE. FNP ne contrôle pas l’interface logique associée au circuit de protection. Seul le service E-Line dont le point de terminaison n’est pas dans un nœud MX est contrôlé par FNP.
FNP prend en charge le redémarrage progressif et les fonctionnalités GRES (Graceful Routing Engine Switchover ).
Voir également
Vue d’ensemble de la mesure des pertes ethernet synthétiques
La mesure de perte synthétique Ethernet (ETH-SLM) est une application qui permet de calculer la perte de trames en utilisant des trames synthétiques au lieu du trafic de données. Ce mécanisme peut être considéré comme un échantillon statistique permettant d’estimer le taux de perte de trame du trafic de données. Chaque point de terminaison d’association de maintenance (MEP) effectue des mesures de perte de trame, ce qui contribue à l’indisponibilité.
Une perte de trames proche de la fin spécifie la perte de trames associées aux trames de données entrantes et une perte de trames lointaines spécifie la perte de trames de trames associées aux trames de données sortantes. Les mesures de perte de trame de bout en bout et de bout en bout contribuent à des secondes gravement erronées et des secondes extrêmes gravement erronées, utilisées conjointement pour déterminer le temps d’indisponibilité. L’ETH-SLM est effectué à l’aide de trames de message de perte synthétique (SLM) et de réponse aux pertes synthétiques (SLR). L’ETH-SLM permet à chaque meP d’effectuer des mesures de perte de trames synthétiques de bout en bout et de bout en bout à l’aide de trames synthétiques, car un service bidirectionnel est défini comme non disponible si l’une des deux directions est jugée non disponible.
Il existe deux types de mesure de la perte de trame, définis par les normes ITU-T Y.1731: ETH-LM et ETH-SLM. Junos OS ne prend en charge que l’ETH-SLM unique. Dans l’ETH-SLM à terminaison unique, chaque meP envoie des trames avec les informations de requête ETH-SLM à son pair MEP et reçoit des trames avec les informations de réponse ETH-SLM de son pair MEP pour effectuer des mesures synthétiques des pertes. L’ETH-SLM à terminaison unique est utilisé pour l’OAM proactif ou à la demande afin d’effectuer des mesures synthétiques de perte applicables à une connexion Ethernet point à point. Cette méthode permet à un député de lancer et de signaler les mesures de perte de bout en bout et quasi-fin associées à une paire de députés qui font partie du même groupe d’entités de maintenance (MEG).
Le Virtual Chassis MX Series ne prend pas en charge la mesure de perte synthétique Ethernet (ETH-SLM).
L’ETH-SLM à fin unique est utilisé pour effectuer des tests à la demande ou en amont en initiant une quantité finie de trames ETH-SLM à un ou plusieurs pairs MEP et en recevant la réponse ETH-SLM des pairs. Les trames ETH-SLM contiennent les informations ETH-SLM qui sont utilisées pour mesurer et signaler à la fois les mesures de perte synthétique de bout et de bout en bout. La mesure des accords de niveau de service (SLA) est le processus de surveillance de la bande passante, des retards, des variations de retard (gigue), de la continuité et de la disponibilité d’un service. Il vous permet d’identifier les problèmes de réseau avant que les clients ne soient affectés par des défauts réseau. En mode proactif, les mesures sla sont déclenchées par une application itératrice. Un itérateur est conçu pour transmettre périodiquement des paquets de mesure SLA sous la forme de trames conformes à l’UIT-Y.1731 pour mesurer la perte de trame synthétique . Ce mode diffère de la mesure des SLA à la demande, à l’initiative de l’utilisateur. En mode à la demande, les mesures sont déclenchées par l’utilisateur via la CLI. Lorsque l’utilisateur déclenche l’ETH-SLM par le biais de la CLI, la demande SLM qui est générée est conformément aux formats de trame spécifiés par la norme ITU-T Y.1731.
Les routeurs ACX5048 et ACX5096 prennent en charge l’ETH-SLM pour les services de couche 2.
Scénarios de configuration de l’ETH-SLM
L’ETH-SLM mesure la perte de trame de bout en bout et de bout entre deux députés qui font partie du même niveau MEG. Vous pouvez configurer l’ETH-SLM pour mesurer les pertes synthétiques pour les MEP orientés vers le haut ou en amont et les MEP orientés vers le bas ou en aval. Cette section décrit les scénarios suivants pour le fonctionnement de l’ETH-SLM :
MeP en amont dans les tunnels MPLS
Prenons un scénario dans lequel un MEP est configuré entre les interfaces réseau utilisateur (UNIs) de deux routeurs MX Series, MX1 et MX2, dans le sens de l’amont. Les MX1 et MX2 sont connectés sur un réseau central MPLS. Des mesures ETH-SLM sont effectuées entre le MEP en amont dans le chemin reliant les deux routeurs. Les MX1 et MX2 peuvent tous deux lancer l’ETH-SLM à la demande ou en amont, ce qui permet de mesurer à la fois les pertes de bout en bout et de proche en bout aux MX1 et MX2, respectivement. Les deux UNIs sont connectés à l’aide d’un service vpn privé virtuel de couche 2 (VPWS) basé sur MPLS.
MeP en aval dans les réseaux Ethernet
Prenons un scénario dans lequel un MEP est configuré entre deux routeurs MX Series, MX1 et MX2, sur les interfaces Ethernet en aval. Les MX1 et MX2 sont connectés dans une topologie Ethernet et le MEP en aval est configuré vers le réseau Ethernet. Des mesures ETH-SLM sont effectuées entre le MEP en aval dans le chemin reliant les deux routeurs. L’ETH-SLM peut être mesuré dans le chemin entre ces deux routeurs.
Prenons un autre scénario dans lequel un MEP est configuré en aval et la protection des services pour un VPWS sur MPLS est activée en spécifiant un chemin de travail ou un chemin de protection sur le MEP. La protection des services protège la connexion de bout en bout du chemin de travail en cas de défaillance. Pour configurer la protection des services, vous devez créer deux chemins de transport distincts : un chemin de travail et un chemin de protection. Vous pouvez spécifier le chemin de travail et protéger le chemin en créant deux associations de maintenance. Pour associer l’association de maintenance à un chemin, vous devez configurer l’interface MEP dans l’association de maintenance et spécifier le chemin comme fonctionnant ou protégé.
Dans un exemple de topologie, un routeur MX Series, MX1, est connecté à deux autres routeurs MX Series, MX2 et MX3, sur un cœur MPLS. La session de gestion des pannes de connectivité (CFM) entre MX1 et MX2 est le chemin de travail sur le MEP et la session CFM entre MX1 et MX3 est le chemin de protection sur le MEP. Les MX2 et MX3 sont à leur tour connectés sur des interfaces Ethernet au MX4 du réseau d’accès. Le MEP en aval est configuré entre MX1 et MX4 qui passent par MX2 (session CFM de travail) et entre MX1 et MX4 qui passent par MX3 (session CFM protégée). L’ETH-SLM est effectué entre ces députés en aval. Dans les DEUX MEP en aval, la configuration est effectuée sur les UNIs MX1 et MX4, de la même manière que les MEP en amont.
Format des messages ETH-SLM
Les messages de perte synthétique (SLM) prennent en charge les requêtes ETH-SLM (Ethernet Synthetic Loss Measurement) à fin unique. Cette rubrique contient les sections suivantes qui décrivent les formats des unités de données de protocole SLM (PDUs), des PDU SLR et la valeur de longueur du type itérateur de données (TLV).
SLM PDU Format
Le format SLM PDU est utilisé par un meP pour transmettre des informations SLM. Les composants suivants sont contenus dans les PDU SLM :
ID MEP source : l’ID MEP source est un champ de 2 octets dans lequel les 13 derniers bits les moins significatifs sont utilisés pour identifier le MEP qui transmet la trame SLM. L’ID MEP est unique au sein du MEG.
ID de test : l’ID de test est un champ de 4 octets défini par le MEP émetteur et est utilisé pour identifier un test lorsque plusieurs tests s’exécutent simultanément entre les MEP (y compris des tests simultanés à la demande et des tests proactifs).
TxFCf — TxFCf est un champ de 4 octets qui transporte le nombre de trames SLM transmises par le MEP vers son meP pair.
Voici les champs d’un PDU SLM :
Niveau MEG : niveau de domaine de maintenance configuré entre 0 et 7.
Version : 0.
OpCode : identifie un type de PDU OAM. Pour le SLM, c’est 55.
Flags : définissez tous les zéros.
TLV Offset — 16.
ID MEP source : champ de 2 octets utilisé pour identifier le MEP qui transmet la trame SLM. Dans ce champ de 2 octets, les 13 derniers bits les moins significatifs sont utilisés pour identifier le MEP qui transmet la trame SLM. L’ID MEP est unique au sein du MEG.
RESV : les champs réservés sont définis sur tous les zéros.
ID de test : champ de 4 octets défini par le meP transmettant et utilisé pour identifier un test lorsque plusieurs tests s’exécutent simultanément entre des MEP (y compris des tests simultanés à la demande et des tests proactifs).
TxFCf : champ de 4 octets qui transporte le nombre de trames SLM transmises par le MEP vers son MEP pair.
TLV en option : une TLV de données peut être incluse dans tout SLM transmis. Aux fins de l’ETH-SLM, la valeur de la TLV de données n’est pas spécifiée.
Fin TLV : valeur de zéro octet.
SLR PDU Format
Le format PDU synthétique de réponse aux pertes (SLR) est utilisé par un MEP pour transmettre des informations SLR. Voici les champs d’un PDU SLR :
Niveau MEG : champ 3 bits dont la valeur est copiée du dernier PDU SLM reçu.
Version : champ 5 bits dont la valeur est copiée du dernier PDU SLM reçu.
OpCode : identifie un type de PDU OAM. Pour le SLR, il est défini comme 54.
Flags : champ de 1 octet copié du PDU SLM.
TLV Offset : champ de 1 octet copié du PDU SLM.
ID MEP source : champ de 2 octets copié du PDU SLM.
ID MEP du répondeur : champ de 2 octets utilisé pour identifier le MEP qui transmet la trame du reflex.
ID de test : champ de 4 octets copié à partir du PDU SLM.
TxFCf : champ de 4 octets copié du PDU SLM.
TxFCb : champ de 4 octets. Cette valeur représente le nombre de trames SLR transmises pour cet ID de test.
TLV facultatif : la valeur est copiée à partir du PDU SLM, le cas échéant.
Fin TLV : champ de 1 octet copié du PDU SLM.
Format TLV iterateur de données
L’itérateur de données TLV spécifie la partie TLV données de la trame de données Y.1731. Le MEP utilise une TLV de données lorsque le MEP est configuré pour mesurer les variations de retard et de retard pour différentes tailles d’images. Les champs d’une TLV de données sont les suivants :
Type : identifie le type de TLV ; la valeur de ce type TLV est Data (3).
Longueur : identifie la taille, en octets, du champ Valeur contenant le modèle de données. La valeur maximale du champ Longueur est 1440.
Modèle de données : - noctet (n désigne la longueur) modèle de bit arbitraire. Le récepteur l’ignore.
Transmission de messages ETH-SLM
La fonctionnalité ETH-SLM peut traiter simultanément plusieurs requêtes SLM (Synthetic Loss Message) entre une paire de meps. Il peut s’agir d’une session SLM proactive ou à la demande. Chaque demande SLM est identifiée de manière unique par un ID de test.
Un meP peut envoyer des requêtes SLM ou répondre à des demandes SLM. Une réponse à une demande SLM est appelée réponse de perte synthétique (SLR). Une fois qu’un MEP détermine une demande SLM à l’aide de l’ID de test, il calcule la perte d’image de bout en bout et proche sur la base des informations du message SLM ou de l’unité de données du protocole SLM (PDU).
Un MEP gère les compteurs locaux suivants pour chaque ID de test et pour chaque MEP homologue surveillé dans une entité de maintenance pour laquelle des mesures de perte doivent être effectuées :
TxFCl : nombre de trames synthétiques transmises à l’homologue MEP pour un id de test. Un MEP source incrémente ce nombre pour la transmission successive de trames synthétiques avec les informations de demande ETH-SLM, tandis qu’une destination ou une meP recevant incrémente cette valeur pour la transmission successive d’images synthétiques avec les informations SLR.
RxFCl : nombre de trames synthétiques reçues de l’homologue MEP pour un id de test. Un MEP source incrémente ce nombre pour la réception successive d’images synthétiques avec des informations SLR, tandis qu’une destination ou une meP reçoit l’incrémente pour la réception successive d’images synthétiques avec les informations de demande ETH-SLM.
Les sections suivantes décrivent les phases de traitement des PDU SLM pour déterminer la perte de trame synthétique :
- Lancement et transmission des demandes SLM
- Réception des SLE et transmission des SLE
- Réception des SLE
- Calcul de la perte de trames
Lancement et transmission des demandes SLM
Un meP transmet régulièrement une demande SLM avec le champ OpCode défini comme 55. Le MEP génère un ID de test unique pour la session, ajoute l’ID MEP source et initialise les compteurs locaux de la session avant le début du SLM. Pour chaque PDU SLM transmis pour la session (ID de test), le compteur local TxFCl est envoyé dans le paquet.
Il n’est pas nécessaire de synchroniser la valeur de l’ID de test entre les MEP de lancement et de réponse, car l’ID de test est configuré au niveau du MEP qui lance et le MEP qui répond utilise l’ID de test qu’il reçoit du MEP qui l’a lancé. L’ETH-SLM étant une technique d’échantillonnage, elle est moins précise que le comptage des trames de service. En outre, la précision de la mesure dépend du nombre de trames SLM utilisées ou de la période de transmission des trames SLM.
Réception des SLE et transmission des SLE
Une fois que le MEP de destination reçoit une trame SLM valide du MEP source, une trame SLR est générée et transmise au MEP demandeur ou source. La trame SLR est valable si le niveau MEG et l’adresse MAC de destination correspondent à l’adresse MAC du MEP destinataire. Tous les champs des PDU SLM sont copiés à partir de la demande SLM, à l’exception des champs suivants :
L’adresse MAC source est copiée à l’adresse MAC de destination et l’adresse source contient l’adresse MAC du MEP.
La valeur du champ OpCode passe de SLM à SLR (54).
L’ID MEP du répondeur est rempli avec l’ID MEP du MEP du MEP.
TxFCb est enregistré avec la valeur du compteur local RxFCl au moment de la transmission de la trame SLR.
Une trame SLR est générée chaque fois qu’une trame SLM est reçue ; par conséquent, RxFCl dans le répondeur est égal au nombre de trames SLM reçues et également au nombre de trames SLR envoyées. Au répondeur ou au meP destinataire, RxFCl est égal à TxFCl.
Réception des SLE
Une fois qu’une trame SLM (avec une valeur TxFCf donnée) est transmise, un MEP s’attend à recevoir une trame SLR correspondante (portant la même valeur TxTCf) dans la valeur de délai d’expiration de son MEP homologue. Les trames SLR reçues après la valeur de délai d’expiration (5 secondes) sont ignorées. À l’aide des informations contenues dans les trames SLR, un MEP détermine la perte de trame pour la période de mesure spécifiée. La période de mesure est un intervalle de temps pendant lequel le nombre de trames SLM transmises est statistiquement suffisant pour effectuer une mesure avec une précision donnée. Un MEP utilise les valeurs suivantes pour déterminer la perte de trames de bout en bout et de bout en bout pendant la période de mesure :
Les dernières valeurs TxFCf et TxFCb des trames SLR reçues, ainsi que la valeur du compteur local RxFCl à la fin de la période de mesure. Ces valeurs sont représentées par TxFCf[tc], TxFCb[tc] et RxFCl[tc], où tc est l’heure de fin de la période de mesure.
Valeurs TxFCf et TxFCb de la première trame SLR reçue après le début de l’essai et du compteur local RxFCl au début de la période de mesure. Ces valeurs sont représentées par TxFCf[tp], TxFCb[tp] et RxFCl[tp], où tp est l’heure de début de la période de mesure.
Pour chaque paquet SLR reçu, le compteur RxFCl local est incrémenté au niveau du MEP d’envoi ou source.
Calcul de la perte de trames
La perte de trame synthétique est calculée à la fin de la période de mesure sur la base de la valeur des compteurs locaux et des informations de la dernière image reçue. Les dernières trames reçues contiennent les valeurs TxFCf et TxFCb. Le compteur local contient la valeur RxFCl. À l’aide de ces valeurs, la perte de trames est déterminée à l’aide de la formule suivante :
Perte de trames (en bout) = TxFCf – TxFCb
Perte de trame (proche de la fin) = TxFCb – RxFCl
performance-monitoring et ses sous-états au niveau de la [edit protocols oam ethernet connectivity-fault-management] hiérarchie) n’est pas prise en charge lorsque l’interface réseau vers réseau (NNI) ou l’interface de sortie est une interface Ethernet agrégée avec des liaisons membres sur des DPC.