Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Surveillance CFM entre les équipements CE et PE

Utilisez ce sujet pour mieux comprendre la surveillance CFM entre les équipements de périphérie du fournisseur et les équipements de périphérie des clients lorsque l’équipement de périphérie du client n’est pas Juniper périphérique. Vous pouvez également comprendre comment les téléviseurs TLV d’état de l’interface, les VLV sur l’état des ports, les systèmes d’ID de châssis et les systèmes de protection des connexions TLV contribuent à surveiller votre réseau.

Notification asynchrone du profil d’action CFM

SUMMARY La notification asynchrone pilotée par CFM permet la synchronisation de l’état des liaisons entre deux équipements CE connectés entre eux par le biais d’une pseudo-connexion filaire provenant de leurs équipements PE respectifs Il émule le scénario comme si deux équipements CE sont directement connectés. CFM fournit une signalisation de bout en bout même si les pe1 et PE2 ne sont pas connectés par un seul réseau, mais par un ensemble de réseaux.

Connectivité de couche 2 entre PE1 et PE2

La Figure 1 est un exemple de déploiement dans lequel il est possible d’utiliser une notification asynchrone basée sur la technologie CFM pour synchroniser l’état des liaisons entre les niveaux CE1 et CE2. Les deux exigences suivantes peuvent être satisfaites avec la configuration de la notification asynchrone.

  • Lorsque la liaison entre PE2 et CE2 passe en panne, la liaison entre le PE1 et le CE1 s’en fait également baisser. Une fois la liaison rétablie, elle doit également restaurer l’état de la liaison PE1 vers CE1. Le changement d’état de la liaison PE1 vers CE1 doit fonctionner de la même manière.

  • En cas de problème de connectivité entre le PE1 et le PE2, il déclenche une liaison entre le PE1 et le CE1 et le PE2 vers le CE2. Si l’état de la connexion est rétabli, il doit restaurer l’état de la liaison aux deux extrémités.

Configuring a CFM Action Profile to Asyncronus Notification

SUMMARY CFM UP-MEP on PE1 to PE2, monitors the connectivity between PE1 to PE2. Use of interface-status-tlv on these UP-MEP end points conveys the link status between PE1 to CE1 to PE2 and link-status between PE2 to CE2 to PE1. Action profile must be configured on PE1 to PE2 to drive asynchronous-notification towards respective CE devices . It is triggered when either adjacency-loss is detected or link-down is detected in the received interface-status-tlv.

  1. Enable asynchronous-notification at interface level

    For example

  2. Configure the action profile and the CFM event(s) to triggered this action profile at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level. You can configure more than one event in the action profile

    For example

    The action asynchronous-notification is not supported with events other than interface-status-tlv down, interface-status-tlv lower-layer-down and adjacency-loss. Any other events configured results in a commit error

    .
  3. Define the action to asynchronous-notification at the [edit protocols oam ethernet connectivity-fault-management action-profile profile-name] hierarchy level.
  4. Define the maintenance domain at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level and specify the maintenance-association parameters

    For example

  5. Configure the generation of interface-status-tlv .it is required if asynchronous-notification configured based on interface-status-tlv.

    For example

  6. Define the maintenance association endpoint at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name] hierarchy level and specify the associated parameters.

    For example

  7. Set asynchronous-notification action profile at the RMEP level.

    For example,

Compréhension de la surveillance CFM entre les équipements CE et PE

Vous pouvez activer une surveillance de la gestion des pannes de connectivité (CFM) entre les équipements de périphérie du fournisseur et les équipements de périphérie des clients lorsque l’équipement de périphérie du client n’est pas Juniper périphérique. Lorsque l’interface est down, CFM propage l’état de l’interface dans les messages CC. Le message CC informe l’équipement de périphérie du client que l’équipement de périphérie du fournisseur est en panne.

Vous pouvez configurer la surveillance CFM en utilisant l’une des deux options suivantes:

  • TLV d’état d’interface (type, longueur et valeur): vous pouvez activer la gestion des pannes de connectivité (CFM) entre les équipements de périphérie du fournisseur et les équipements de périphérie du client lorsque l’équipement de périphérie du client n’est pas un équipement Juniper en utilisant Interface Status TLV. Lorsque l’interface est down, CFM propage l’état de l’interface à l’aide de la technologie TLV d’état de l’interface. L’état de l’interface TLV indique l’état de l’interface sur laquelle le MEP transmet le CCM ou l’interface inférieure suivante dans le IETF RFC 2863 IF-MIB. Ainsi, l’équipement de périphérie du client est conscient que l’équipement de périphérie du fournisseur est en panne. Pour configurer la surveillance CFM à l’aide de interface status TLV, utilisez interface-status-tlv l’instruction au niveau [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check de la hiérarchie. Il s’agit de l’option standard.

  • RDI (Indication de défaillance à distance): à partir du 17.3R1 de publication Junos OS, vous pouvez surveiller les pannes de connectivité entre les équipements de périphérie du fournisseur et les équipements de périphérie du client lorsque l’équipement de périphérie du client n’est pas un équipement Juniper en utilisant le bit de indication de défaillance à distance (RDI). Lorsque vous activez la surveillance CFM, CFM propage l’état de l’équipement de périphérie du fournisseur via le bit de indication de défaillance à distance (RDI) dans les messages CC. Ainsi, l’équipement de périphérie du client est conscient que l’équipement de périphérie du fournisseur est en panne. Le bit RDI est autorisé lorsque le service est en arrière. Pour configurer la surveillance CFM à l’aide du bit RDI, utilisez interface-status-send-rdi l’instruction au niveau [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check de la hiérarchie. Cette option est requise si l’équipement de périphérie du client ne prend pas en charge la technologie TLV état d’interface.

Remarque :

Lorsque l’interface est configurée pour CCC et que vous avez configuré RDI, un bit RDI est envoyé. CFM ne surveille pas l’état de l’interface. Si la panne CCC est définie lorsque l’interface n’est pas en veille, un bit RDI est envoyé avec les messages CC si vous avez configuré RDI.

Cas d’utilisation de multi-homing actif unique à l’aide du bit RDI

Prenons la topologie suivante: deux équipements de périphérie fournisseurs (PE1 et PE2) et deux équipements de périphérie clients (CE1 et CE2). LE PE1 est en état actif alors que le PE2 est en veille. CFM down MEP est configuré entre le PE et le CE. CFM détecte que la CCC est down et que le CFM vers le bas du MEP est configuré, les messages CC générés ont le bit RDI. Les messages CC de PE2 au CE2 sont placés sur le bit RDI pour indiquer l’état bloqué. Lorsque PE2 devient actif, le CCM down est autorisé et le bit RDI est autorisé à partir des messages CC suivants.

Multihoming actif/actif Cas d’utilisation à l’aide du bit RDI

Prenons la topologie dans laquelle se trouve deux équipements de périphérie fournisseurs (PE1 et PE2) et deux équipements de périphérie clients (CE1 et CE2). LE PE1 est en état actif alors que le PE2 est en veille. Si le CFM down MEP n’est pas configuré entre le PE et le CE pour surveiller la connectivité des liaisons, les messages CC générés n’ont pas le bit RDI. CFM down MEP est configuré entre le PE et le CE. CFM détecte que la CCC est down et que le CFM vers le bas du MEP est configuré, les messages CC générés ont le bit RDI. Les messages CC de PE2 au CE2 sont placés sur le bit RDI pour indiquer l’état bloqué. Lorsque PE2 devient actif, le CCM down est autorisé et le bit RDI est autorisé à partir des messages CC suivants.

Configuration de l’état des ports TLV et état de l’interface TLV

Présentation des VTT

Le type, la longueur et la valeur (TV) sont décrits dans la norme IEEE 802.1ag pour CFM comme méthode d’encodage des informations de longueur variable et/ou facultatives dans un PDU. Les VTT ne sont pas alignés sur un mot particulier ou une limite octet. Les VTL se suivent sans aucune rempage entre eux.

Tableau 1 affiche le format TLV et indique s’il est requis ou facultatif.

Tableau 1 : Format des téléviseurs À LAN

Paramètre

Octet (séquence)

Description

Type

1

Obligatoire. Si 0, aucun champ Longueur ou valeur ne s’en suit. Si ce n’est pas 0, le champ Longueur suit au moins le champ Type.

Longueur

2–3

Requis si le champ Type n’est pas 0. Non présent si le champ type est 0. Les 16 bits du champ Longueur indiquent la taille, dans les octets, du champ Valeur. 0 dans le champ Longueur indique qu’il n’y a pas de champ de valeur.

Valeur

4

Longueur spécifiée par le champ Longueur. Optionnel. Non présent si le champ Type est 0 ou si le champ de longueur est 0.

Divers téléviseurs pour PDUS CFM

Tableau 2 affiche un ensemble de VTV définis par IEEE 802.1ag pour différents types de CFM PDU. Chaque TLV peut être identifié par la valeur unique attribuée à son champ type. Certaines valeurs de champ de type sont réservées.

Tableau 2 : Type de valeurs de champ pour divers téléviseurs TLV pour PDUS CFM

TLV ou organisation

Type de champ

Fin du TLV

0

ID expéditeur TLV

1

État des ports TLV

2

Lv des données

3

État de l’interface TLV

4

Réponse TLV entrée

5

Réponse TLV sortie

6

Identifiant de sortie LTM TLV

7

Identifiant de sortie LTR TLV

8

Réservé au IEEE 802.1

Entre 9 et 30

TLV spécifiques à l’entreprise

31

Définition de l’ITU-T Y.1731

Entre 32 et 63

Réservé au IEEE 802.1

Entre 64 et 255

Chaque TLV n’est pas applicable à tous les types de PDUS CFM.

  • VTC applicables aux messages CCM (Continuity Check):

    • Fin du TLV

    • ID expéditeur TLV

    • État des ports TLV

    • État de l’interface TLV

    • TLV spécifiques à l’entreprise

  • Téléviseurs LBM (Loopback Message):

    • Fin du TLV

    • ID expéditeur TLV

    • Lv des données

    • TLV spécifiques à l’entreprise

  • TLV applicables pour la réponse en boucle (LBR):

    • Fin du TLV

    • ID expéditeur TLV

    • Lv des données

    • TLV spécifiques à l’entreprise

  • VLAN applicables aux messages de liaison (LTM):

    • Fin du TLV

    • Identifiant de sortie LTM TLV

    • ID expéditeur TLV

    • TLV spécifiques à l’entreprise

  • VLAN applicables pour la réponse par liaison (LTR):

    • Fin du TLV

    • Identifiant de sortie LTR TLV

    • Réponse TLV entrée

    • Réponse TLV sortie

    • ID expéditeur TLV

    • TLV spécifiques à l’entreprise

Les TV suivants sont actuellement pris en charge dans les PDUS CFM applicables:

  • Fin du TLV

  • Réponse TLV entrée

  • Réponse TLV sortie

  • Identifiant de sortie LTR TLV

  • Identifiant de sortie LTM TLV

  • Lv des données

Prise en charge de téléviseurs supplémentaires en option

Les TLV supplémentaires supplémentaires suivants sont pris en charge:

  • État des ports TLV

  • État de l’interface TLV

MX Series la configuration de l’état des ports TLV et de l’état de l’interface TLV. La configuration du TLV d’état du port permet à l’opérateur de contrôler la transmission de TLV d’état de port dans des PDUS CFM.

Remarque :

Bien que les déclarations de configuration TLV d’état de port soient visibles dans le CLI sur les routeurs M120 et M320, il n’est pas possible de configurer TLV d’état de port sur ces systèmes. La fonction TLV d’état des ports peut être activée sur une interface MEP uniquement s’il s’agit d’une interface logique de pontage, ce qui n’est pas possible sur ces systèmes.

Pour plus d’informations sur la configuration, consultez les sections suivantes:

État des ports TLV

L’état du port TLV indique la capacité du port de pont sur lequel réside le MEP transmis de transmettre des données ordinaires, quel que soit le statut de l’MAC. La valeur de ce TLV est motivée par la variable enableRmepDefect MEP, comme illustré dans Tableau 4 . Le format de cette TLV est indiqué dans Tableau 3 .

Tout changement de valeur des TLV d’état des ports déclenche une transmission supplémentaire de ces ports de pontage de M CCM meP.

Tableau 3 : Format TLV sur l’état des ports

Paramètre

Octet (séquence)

Type = 2

1

Longueur

2–3

Valeur Tableau 4 (voir)

4

Tableau 4 : Valeurs TLV d’état de port

Mnémonique

Des données ordinaires transitent librement à travers le port

Valeur

ps Blocage

non: enableRmepDefect = faux

1

psUp

Oui: enableRmepDefect = vrai

2

La variable MEP est une variable booléen indiquant si des trames sur l’instance de service surveillés par les associations de maintenance sont activées par le protocole Spanning Tree et la gestion de la topologie VLAN pour traverser ce port de enableRmepDefect pontage. La valeur de ces valeurs est définie selon la valeur réelle des valeurs ci-après:

  • Le port de pont est placé dans un état où le trafic peut le passer.

  • Le port de pont exécute plusieurs instances du Spanning Tree.

  • L’interface MEP n’est pas associée à un domaine de pontage.

Configuration de l’état des ports TLV

Junos OS configuration des TLV d’état des ports, vous permet de contrôler la transmission de celvère dans des PDUS CCM. Le Junos OS fournit cette configuration au niveau de vérification de la continuité. Par défaut, le CCM n’inclut pas le TLV d’état du port. Pour configurer le TLV d’état du port, utilisez port-status-tlv l’instruction au niveau [edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check] de la hiérarchie.

Remarque :

La configuration TLV d’état des ports n’est pas IEEE 802.1ag. Cette Junos OS pour offrir plus de flexibilité à l’opérateur. toutefois, il reçoit et traite les MCC avec un TLV d’état de port, indépendamment de cette configuration.

Voici un exemple des instructions de configuration suivantes:

Vous ne pouvez pas activer la transmission TLV d’état de port dans les deux cas suivants:

  • Si l’interface MEP sous maintenance-association n’est pas un pont type.

  • Si le MEP est configuré sur une interface physique.

Affichage dulv d’état du port reçu

La Junos OS enregistre le dernier TLV d’état de port reçu d’un MEP distant. Si la valeur d’état du port reçu ne correspond pas à l’une des valeurs standard répertoriées, la commande l’affiche Tableau 4show comme « inconnue ». Vous pouvez afficher le dernier TLV d’état des ports enregistré à l’aide de la show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier commande, comme dans l’exemple suivant:

Affichage de l’état des ports transmis TLV

Le Junos OS enregistre le dernier TLV sur l’état des ports transmis auprès d’un meP local. Si la transmission du TLV d’état du port n’a pas été activée, la commande show s’affiche « aucune ». Vous pouvez afficher le dernier TLV d’état des ports enregistrés à l’aide de la show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier commande, comme dans l’exemple suivant:

État de l’interface TLV

L’état de l’interface TLV indique l’état de l’interface sur laquelle le MEP transmet le CCM ou l’interface inférieure suivante dans le IETF RFC 2863 IF-MIB. Le format de cette TLV est indiqué dans Tableau 5 . Les valeurs indiquées sont affichées dans Tableau 6 .

Tableau 5 : Format TLV d’état de l’interface

Paramètre

Octet (séquence)

Type = 4

1

Longueur

2–3

Valeur Tableau 6 (voir)

4

Tableau 6 : Valeurs TLV d’état d’interface

Mnémonique

État de l’interface

Valeur

fin de vie

jusqu’à

1

estdown

vers le bas

2

test

test

3

est Connu

Inconnu

4

isDormant

en sommeil

5

isNotPrésent

sans déclaration

6

isLowerLayerDown

couche inférieure (lowerLayerDown)

7

Remarque :

Lorsque le statut opérationnel d’une interface logique passe de l’état inférieur (valeur de 2) à l’état inférieur de la couche inférieure (valeur d’état de 7) et vice versa, le piège SNMP de linkdown n’est pas généré. Par exemple, si vous configurez une offre d’interface Ethernet agrégée avec une balise VLAN et ajoutez une interface physique de l’état opérationnel vers le bas à l’offre, l’état opérationnel de l’offre d’interface logique Ethernet agrégée à ce stade est inférieur à la couche inférieure (7). Si vous prenez le MIC associé à l’interface hors ligne, le piège de linkdown n’est pas généré lorsque l’interface logique passe de l’état inférieur à l’état inférieur.

De même, envisagez un autre scénario d’exemple dans lequel une interface physique est ajoutée à une offre Ethernet agrégée qui dispose du balisage VLAN et de l’interface logique Ethernet agrégée est désactivée. Lorsque l’interface logique est désactivée, l’état opérationnel de l’interface logique change de direction. Si vous désactivez l’interface physique faisant partie de l’offre Ethernet agrégée, l’état opérationnel de l’interface logique Ethernet agrégée reste en baisse. Si vous reenregisez l’interface logique Ethernet agrégée, son statut opérationnel sera réduit de couche inférieure à inférieure. Le piège SNMP de linkdown n’est pas généré à ce stade.

Configuration de l’état de l’interface TLV

La Junos OS fournit une prise en charge de la configuration des TLV d’état des interfaces, ce qui permet aux opérateurs de contrôler la transmission de ce TLV dans des PDUS CCM par le biais d’une configuration au niveau de la vérification de continuité.

Remarque :

Cette configuration n’est pas obligatoire IEEE 802.1ag ; sont plutôt fournis pour offrir plus de flexibilité à l’opérateur. Le Junos OS reçoit et traite les MCC avec le TLV d’état de l’interface, indépendamment de cette configuration.

L’état de l’interface la configuration TLV est affichée ci-dessous:

Remarque :

Le Junos OS prend en charge la transmission de trois valeurs possibles sur sept seulement pour le TLV d’état d’interface. Les valeurs prise en charge sont 1, 2 et 7. Toutefois, le Junos OS peut recevoir une valeur quelconque pour le TLV état d’interface.

Affichage dulv d’état de l’interface de réception

La Junos OS enregistre le dernier TLV d’état d’interface reçu auprès du meP distant. Si la valeur d’état de l’interface reçue ne correspond pas à l’une des valeurs standard répertoriées dans la commande, la commande s’affiche Tableau 5show « inconnue ».

Vous pouvez afficher cette dernière interface enregistrée État TLV à l’aide de la show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier commande, comme dans l’exemple suivant:

Affichage de l’état de l’interface transmise TLV

La Junos OS enregistre le dernier TLV d’état d’interface transmis à partir d’un mep local. Si la transmission d’État d’interface TLV n’a pas été activée, la commande show affiche « aucune ».

Vous pouvez afficher le dernier TLV d’état d’interface transmis à l’aide de la show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier commande, comme dans l’exemple suivant:

Défauts d’état MAC

Le Junos OS fournit des informations sur les défauts d’état MAC, ce qui indique qu’un ou plusieurs des meP distants signalent une défaillance de son service TLV d’état de port ou de l’état de l’interface TLV. Il indique « oui » si un meP distant signale que son interface n’est pas en cours de création (par exemple, si au moins une interface mep distante est indisponible), ou si tous les mep distants signalent un TLV d’état de port qui contient une valeur autre que la mise en service (par exemple, tous les ports de pontage distants ne sont pas des données de communication). Il est possible d’utiliser deux commandes pour afficher la indication de défauts de statut show MAC.

Utilisez la mep-database commande pour afficher les défauts d’état MAC:

Utilisez la interfaces commande pour afficher les défauts d’état MAC:

Configuration de la prise en charge du profil d’action des meP distants

En fonction des valeurs des paquets CCM reçus et de ceux-ci, vous pouvez prendre des mesures spécifiques à l’aide des interface-status-tlvport-status-tlv options interface-downaction-profile proposées. Plusieurs profils d’action peuvent être configurés sur le routeur, mais un seul profil d’action peut être attribué à un MEP distant.

Le profil d’action peut être configuré avec au moins un événement pour déclencher l’action ; mais l’action s’enclenche en cas d’un de ces événements. Il n’est pas nécessaire que tous les événements configurés se produisent. action

Un profil d’action ne peut être appliqué qu’au niveau mep distant.

L’exemple suivant affiche une configuration de profil d’action avec des commentaires explicites ajoutés:

Surveillance d’un profil d’action du MEP à distance

Vous pouvez utiliser la commande pour afficher l’état du profil d’action d’un show oam ethernet connectivity-fault-management mep-database MEP distant, comme dans l’exemple suivant:

show oam ethernet connectivity-fault- management mep-database remote-mep (Événement du profil d’action)

Configuration de l’ID de châssis TLV

Dans la version 16.1R2, vous pouvez configurer l’Junos OS pour envoyer l’ID TLV de l’expéditeur ainsi que les paquets. L’ID TLV de l’expéditeur est un service de recherche et de contrôle de continuité (TLV) en option qui est envoyé dans les messages de vérification de continuité, les messages de bouclisation et les messages de trace de liens (LTM), tels que spécifiés dans la norme IEEE 802.1ag. L’ID TLV de l’expéditeur contient l’ID de châssis, qui est l’adresse MAC unique basée sur CFM de l’équipement, et l’adresse IP de gestion, qui est une adresse IPv4 ou IPv6.

La valeur du champ dans le TLV indique si le TLV contient ou non les informations d’ID de length châssis. Les valeurs possibles pour le champ sont de zéro () ou n’importe quel numéro valide, ce qui indique l’absence ou la présence d’informations d’ID de châssis dans le length0 TLV, respectivement.

Vous pouvez activer la Junos OS’envoyer l’ID TLV de l’expéditeur au niveau mondial à l’aide de la set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlv commande. Si l’ID TLV de l’expéditeur est configuré au niveau mondial, le domaine de maintenance par défaut, l’association de maintenance et la demi-fonction MIP (maintenance association Intermediate Point) héritent de cette configuration.

Vous pouvez également configurer l’ID TLV de l’expéditeur selon les niveaux hiérarchiques suivants:

  • [edit protocols oam ethernet connectivity-fault-management].

  • [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name maintenance-association maintenance-association-name continuity-check].

La configuration TLV de l’ID de l’expéditeur au niveau maintenance-association a priorité sur la configuration globale.

Remarque :

L’ID TLV de l’expéditeur est pris en charge uniquement pour les PDUS 802.1ag et n’est pas pris en charge pour les unités de données de protocole (PDUS) de surveillance des performances.

Configuration du traitement des messages MAC en mode CET

En mode Transport Ethernet opérateur (CET), les routeurs MX Series sont utilisés comme routeurs de périphérie du fournisseur (PE) et Nokia Siemens Networks A2200 Carrier Commutateurs Ethernet (appelés équipements E-domain) qui exécutent des protocoles standard sont utilisés dans le côté accès. Sur les routeurs MX Series, les pseudowires VPLS sont configurés de manière dynamique via le protocole de distribution d’étiquettes (LDP). Sur les équipements E-domain, des modifications de topologie sont détectées via des sessions de gestion des défaillances de connectivité (CFM) s’exécutant entre les équipements E-domain et les routeurs MX SERIES PE. Les routeurs MX Series PE peuvent down l’interface Ethernet opérateur en cas de perte de connectivité CFM. Cela déclenche une couleur MAC locale ainsi qu’une notification d’origine MAC ciblée (T-LDP) qui est envoyée vers le PE MX Series distant pour déclencher une attaque MAC.

En mode interopérables CET, les routeurs MX Series doivent fonctionner de façon interopérable avec les équipements d’accès Ethernet opérateur Ax100 Carrier De Nokia Networks (appelés équipements À domaine) qui exécutent des protocoles hérités. Nokia Siemens Networks Les équipements A4100 et A8100 de Nokia Siemens Networks agissent comme un intermédiaire entre les routeurs MX Series PE et les équipements À domaine. Ces équipements intermédiaires exécutent des procédures de fonction d’interconnexion (IWF) afin de pouvoir exécuter des sessions de gestion de l’administration des opérations (OAM) entre les routeurs MX Series et les équipements A-domain. Il n’y a pas de pseudowire VPLS entre les routeurs MX Series PE et les équipements de niveau intermédiaire A4100 et A8100 de Nokia Siemens Networks. Il n’existe donc aucun protocole LDP s’exécutant entre les routeurs PE pour envoyer des notifications de modification de la topologie. Afin de communiquer les modifications de topologie, les routeurs MX Series peuvent déclencher une couleur MAC et la propager dans le centre. MX Series routeurs d’entreprise peuvent utiliser des profils d’action basés sur l’événement TLV (Connection Protection Type Length Value). Le profil d’action regroupe l’interface logique de périphérie opérateur dans les routeurs MX SERIES PE, qui déclenchent une couleur MAC locale et propagent la modification de topologie au cœur à l’aide d’une notification LDP.

VPLS ne surveille aucune connectivité de bout en bout. Les anneaux d’accès sont surveillés indépendamment en exécutant CFM vers le bas de plusieurs points de terminaux (MEP) sur les chemins de travail et de protection pour chacun des services entre les équipements E-domain et les routeurs MX Series PE, et entre les équipements A-domain et les routeurs PE MX Series l’IWF hébergé par les équipements Nokia Siemens Networks A-4100. En cas de défaillance de connectivité sur le chemin de travail, les équipements Ax200 de Nokia Siemens Networks effectuent un basculement vers le chemin de protection, en déclenchement d’une notification des changements de topologie (sous la forme de VTC transportés dans CCM) pour être envoyés sur le chemin actif.

Figure 1 : Topologie double d’opérations inter-opérations cetTopologie double d’opérations inter-opérations cet

Figure 1 décrit la double topologie d’accès sur MX Series PE connectés au domaine A. Lorsqu’un équipement d’un domaine déclenche un basculement, il commence à commuter le trafic de service vers le nouveau chemin actif. Cette modification est communiquée dans les unités de données de protocole HELLO envoyées par cet équipement de domaine sur les chemins de travail et de protection. Lorsque l’IWF dans le A4100 recieve ces PDUs HELLO, il les convertit en messages CCM standard et insère également un TLV de protection contre les connexions. Le champ « Protection à l’utilisation » du champ de protection des connexions TLV est encodé avec le chemin actuellement actif et est inclus dans le message CCM. Les messages de CCM sont reçus par MX Series PE via le spoke VLAN dans le A4100. Dans le scénario à double accueil ci-dessus, un routeur PE MX Series surveille le chemin de travail, et l’autre MX Series PE surveille le chemin de protection.

Une couleur MAC se produit lorsque la session CFM qui surveille le chemin de travail détecte que le trafic de service est passé au chemin de protection ou lorsque la session CFM qui surveille le chemin de protection détecte que le trafic du service est passé au chemin de travail.

Figure 2 : Topologie inter-opérations cet rattachée à une double opérationTopologie inter-opérations cet rattachée à une double opération

Figure 2 décrit la double topologie connectée sur MX Series PE connectés au domaine A. Le mécanisme de couleur MAC utilisé dans ce cas est également le même que celui utilisé pour le domaine A dans le scénario double d’accueil (Figure 1). Toutefois, les deux sessions CFM sont hébergées par un seul routeur MX SERIES PE. Lorsque le routeur Ax100 dans l’environnement A détecte des changements sur la topologie, le routeur PE MX Series reçoit le message TLV de protection des connexions dans le message CCM concernant les chemins de travail et de protection avec la valeur de « Protection à l’utilisation » indiquant le chemin actif. En fonction de l’événement généré pour la session CFM, le routeur MX SERIES PE baisse l’interface appropriée et déclenche une couleur MAC locale.

Configuration d’un profil d’action TLV pour la protection des connexions

Un profil d’action peut être configuré pour effectuer l’action en fonction des valeurs des interface-downconnection-protection-tlv paquets CCM reçus.

L’exemple suivant affiche une configuration de profil d’action avec des commentaires explicites ajoutés:

Exemple: Configuration d’un profil d’action basé sur les téléviseurs à ligne de protection des connexions

Cet exemple montre comment configurer un profil d’action basé sur le TLV de protection des connexions à des fins de déclenchement de couleurs MAC en fonction des changements de topologie d’un réseau CET.

Conditions préalables

Cet exemple utilise les composants matériels et logiciels suivants:

  • Junos OS version 11.2 ou ultérieure

  • Un routeur PE MX Series

Présentation et topologie

La topologie physique d’un réseau CET à l’aide de routeurs PE MX Series est montrée dans Figure 3

Topologie

Figure 3 : Topologie du réseau CETTopologie du réseau CET

Les définitions suivantes décrivent le sens de l’abréviation et des termes utilisés dans Figure 3 .

  • Équipement de périphérie fournisseur (PE): un équipement ou un ensemble d’équipements, à la périphérie du réseau du fournisseur, qui présente la vue du site du client par le fournisseur.

  • E-domain— Nokia Siemens Networks Carrier Commutateurs Ethernet qui exécutent des protocoles standard et sont utilisés dans le côté accès.

  • Domaine --Nokia Siemens Networks Carrier Commutateurs Ethernet qui exécutent les protocoles hérités.

Configuration

Procédure

Procédure étape par étape

Pour configurer un profil d’action basé sur la protection des connexions TLV, préformez ces tâches:

  1. Configurer un profil d’action

  2. Si le TLV de protection des connexions reçoit la valeur SET « Protection-in-use », alors ce dernier doit utiliser le chemin de protection.

  3. Si la protection de connexion TLV est reçue avec une valeur « Protection-in-use » de RESET, alors la protection de connexion TLV doit utiliser le chemin de travail

  4. Configurez le profil d’action pour faire baisser l’interface

Résultats

Vérifier les résultats de la configuration

Tableau de l'historique des versions
Version
Description
17.3R1
À partir de Junos OS Release 17.3R1, vous pouvez surveiller les défaillances de connectivité (CFM) entre les équipements de périphérie du fournisseur et les équipements de périphérie du client lorsque l’équipement de périphérie du client n’est pas un équipement Juniper en utilisant le bit de indication de défaillance à distance (RDI).
16.1
Dans la version 16.1R2, vous pouvez configurer l’Junos OS pour envoyer l’ID TLV de l’expéditeur ainsi que les paquets.