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 cette rubrique pour en savoir plus sur la surveillance 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 client n’est pas un équipement Juniper. Vous découvrirez également comment les TLV d’état de l’interface, les TLV d’état des ports, les TLV d’ID de châssis et la protection des connexions TLV vous aident à surveiller votre réseau.

Notification asynchrone du profil d’action CFM

SUMMARY La notification asynchrone pilotée par CFM permet de synchroniser l’état des liaisons entre deux équipements CE connectés l’un à l’autre via un pseudo fil provenant de leurs équipements PE respectifs Il émule scénario comme si deux équipements CE sont directement connectés. CFM fournit une signalisation de bout en bout même si pe1 et PE2 ne sont pas connectés via un seul réseau, mais un ensemble de réseaux.

Connectivité de couche 2 entre PE1 et PE2

La figure 1 est un exemple de scénario de déploiement dans lequel une notification asynchrone basée sur CFM peut être utilisée pour synchroniser l’état de la liaison entre ce1 et CE2. Deux exigences peuvent être satisfaites avec la configuration de la notification asynchrone.

  • Lorsque la liaison entre PE2 et CE2 tombe en panne, la liaison entre PE1 et CE1 est également diminuée. Lorsque la liaison est restaurée, elle doit également rétablir l’état de la liaison PE1 vers CE1. Le changement d’état de la liaison entre PE1 et CE1 devrait fonctionner de la même manière.

  • En cas de problème de connectivité entre PE1 et PE2, il déclenche une liaison entre PE1 et CE1 et PE2 vers 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,

Comprendre la surveillance CFM entre les équipements CE et PE

Vous pouvez activer la 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 du client lorsque l’équipement de périphérie du client n’est pas un équipement Juniper. Lorsque l’interface est en panne, CFM propage le statut 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 à l’aide de l’une des deux options suivantes :

  • Statut de l’interface TLV (type, longueur et valeur) : vous pouvez activer la surveillance CFM (Connectivity Fault Management) 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 client n’est pas un équipement Juniper à l’aide de l’TLV d’état de l’interface. Lorsque l’interface est en panne, CFM propage le statut de l’interface en utilisant l’état de l’interface TLV. Le TLV d’état de l’interface indique l’état de l’interface sur laquelle le MEP transmettant le CCM est configuré, ou l’interface inférieure suivante dans la RFC 2863 IF-MIB de l’IETF. 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 l’TLV d’état de l’interface, utilisez l’instruction interface-status-tlv au niveau de la [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check hiérarchie. C’est l’option standard.

  • RDI (Remote Defect Indication) : à partir de la version 17.3R1 de Junos OS, vous pouvez activer la 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 du client lorsque l’équipement de périphérie du client n’est pas un équipement Juniper à l’aide du bit RDI (Remote Defect Indication). Lorsque vous activez la surveillance CFM, CFM propage l’état de l’équipement de périphérie du fournisseur via le bit RDI (Remote Défaut Indication) 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 de nouveau opérationnel. Pour configurer la surveillance CFM à l’aide du bit RDI, utilisez l’instruction interface-status-send-rdi au niveau de la [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check hiérarchie. Cette option est requise si l’équipement de périphérie du client ne prend pas en charge l’état de l’interface TLV.

REMARQUE :

Lorsque l’interface est définie sur CCC et que vous avez configuré RDI, le bit RDI est envoyé. CFM ne surveille pas l’état de l’interface. Si la commande CCC est définie alors que l’interface n’est pas de réserve, le bit RDI est envoyé avec les messages CC si vous avez configuré RDI.

Cas d’utilisation unique de multi-homing actif avec RDI bit

Prenons la topologie suivante où il existe deux équipements de périphérie des fournisseurs (PE1 et PE2) ainsi que deux équipements de périphérie client (CE1 et CE2). PE1 est à l’état actif tandis que PE2 est en état de réserve. Le MEP vers le bas de CFM est configuré entre le PE et le CE. CFM détecte que le CCC est en panne et parce que le MEP de descente CFM est configuré, les messages CC générés ont le bit RDI. Les messages CC de PE2 à CE2 ont le bit RDI défini pour indiquer l’état bloqué. Lorsque le PE2 devient actif, CCM est désactivé et le bit RDI est supprimé des messages CC suivants.

Multihébergement actif/actif Cas d’utilisation avec RDI bit

Prenons la topologie où il existe deux équipements de périphérie des fournisseurs (PE1 et PE2) et deux équipements de périphérie client (CE1 et CE2). PE1 est à l’état actif tandis que PE2 est en état de réserve. Si le MEP vers le bas de CFM n’est pas configuré entre le PE et le CE pour surveiller la connectivité de la liaison, les messages CC générés n’ont pas le bit RDI. Le MEP vers le bas de CFM est configuré entre le PE et le CE. CFM détecte que le CCC est en panne et parce que le MEP de descente CFM est configuré, les messages CC générés ont le bit RDI. Les messages CC de PE2 à CE2 ont le bit RDI défini pour indiquer l’état bloqué. Lorsque le PE2 devient actif, CCM est désactivé et le bit RDI est supprimé des messages CC suivants.

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

Présentation des TLV

Le type, la longueur et la valeur (TLV) sont décrits dans la norme IEEE 802.1ag pour CFM comme méthode d’encodage de longueur variable et/ou d’informations facultatives dans un PDU. Les TLV ne sont pas alignées sur des limites de mots ou d’octets particuliers. Les TLV se suivent sans rembourrage entre eux.

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

Tableau 1 : Format des TLV

Paramètre

Octet (séquence)

Description

Type

1

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

Length

2–3

Obligatoire 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, en octets, du champ Valeur. 0 dans le champ Longueur indique qu’il n’y a pas de champ 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 Longueur est 0.

Divers TLV pour PDU CFM

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

Tableau 2 : Saisissez les valeurs de champ de divers TLV pour les PDU CFM

TLV ou organisation

Champ de type

Fin TLV

0

TLV d’identification de l’expéditeur

1

TLV d’état des ports

2

TLV de données

3

TLV d’état de l’interface

4

TLV d’entrée de réponse

5

TLV de sortie de réponse

6

TLV de l’identifiant sortant LTM

7

Identifiant sortant LTR TLV

8

Réservé pour IEEE 802.1

Entre 9 et 30

TLV spécifiques à l’entreprise

31

Défini par ITU-T Y.1731

Entre 32 et 63

Réservé pour IEEE 802.1

Entre 64 et 255

Toutes les TLV ne s’appliquent pas à tous les types de PDU CFM.

  • TLV applicables au message de contrôle de la continuité (CCM) :

    • Fin TLV

    • TLV d’identification de l’expéditeur

    • TLV d’état des ports

    • TLV d’état de l’interface

    • TLV spécifiques à l’entreprise

  • TLV applicables aux messages de bouclage (LBM) :

    • Fin TLV

    • TLV d’identification de l’expéditeur

    • TLV de données

    • TLV spécifiques à l’entreprise

  • TLV applicables pour la réponse de bouclage (LBR) :

    • Fin TLV

    • TLV d’identification de l’expéditeur

    • TLV de données

    • TLV spécifiques à l’entreprise

  • TLV applicables au message linktrace (LTM) :

    • Fin TLV

    • TLV de l’identifiant sortant LTM

    • TLV d’identification de l’expéditeur

    • TLV spécifiques à l’entreprise

  • TLV applicables pour la réponse linktrace (LTR) :

    • Fin TLV

    • Identifiant sortant LTR TLV

    • TLV d’entrée de réponse

    • TLV de sortie de réponse

    • TLV d’identification de l’expéditeur

    • TLV spécifiques à l’entreprise

Les TLV suivants sont actuellement pris en charge dans les PDU CFM applicables :

  • Fin TLV

  • TLV d’entrée de réponse

  • TLV de sortie de réponse

  • Identifiant sortant LTR TLV

  • TLV de l’identifiant sortant LTM

  • TLV de données

Prise en charge des TLV supplémentaires en option

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

  • TLV d’état des ports

  • TLV d’état de l’interface

Les routeurs MX Series prennent en charge la configuration de l’état des ports TLV et l’état de l’interface TLV. La configuration de l’TLV d’état du port permet à l’opérateur de contrôler la transmission du TLV d’état du port dans les PDU CFM.

REMARQUE :

Bien que les instructions de configuration TLV statut du port soient visibles dans l’interface cli sur les routeurs M120 et M320, l’état TLV des ports ne peut pas être configuré sur ces systèmes. L’état TLV de port peut être activé sur une interface MEP uniquement s’il s’agit d’une interface logique de pont, ce qui n’est pas possible sur ces systèmes.

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

TLV d’état des ports

Le TLV d’état du port indique la capacité du port de pont sur lequel réside le MEP émetteur à transmettre des données ordinaires, quel que soit le statut du MAC. La valeur de cette TLV est augmentée par la variable enableRmepDefectMEP , comme illustré dans Tableau 4. Le format de cette TLV est affiché dans Tableau 3.

Toute modification de la valeur des TLV d’état des ports déclenche une transmission supplémentaire des CCM MEP des ports de pont.

Tableau 3 : Format TLV statut du port

Paramètre

Octet (séquence)

Type = 2

1

Length

2–3

Valeur (Voir Tableau 4)

4

Tableau 4 : Valeurs TLV statut des ports

Mnémonique

Données ordinaires transitant librement par le port

Valeur

psBlocked

Non: enableRmepDefect = faux

1

psUp

Oui: enableRmepDefect = vrai

2

La variable MEP est une variable enableRmepDefect booléenne qui indique si les trames sur l’instance de service contrôlées par les associations de maintenance sont activées pour passer par ce port de pont par le protocole Spanning Tree et la gestion de la topologie VLAN. Il est défini sur VRAI si :

  • Le port de pont est défini dans un état où le trafic peut passer par lui.

  • 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 TLV du port

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

REMARQUE :

La configuration de l’état TLV port n’est pas obligatoire par IEEE 802.1ag. Junos OS le fournit afin d’offrir plus de flexibilité à l’opérateur ; mais il reçoit et traite les CCM avec un TLV d’état de port, quelle que soit cette configuration.

Voici un exemple des instructions de configuration :

Vous ne pouvez pas activer l’état TLV port dans les deux cas suivants :

  • Si l’interface MEP dans le cadre de la maintenance-association n’est pas de type pont.

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

Affichage de l’état des ports reçus TLV

Junos OS enregistre le dernier port TLV reçu d’un meP distant. Si la valeur reçue Port Status ne correspond pas à l’une des valeurs standard répertoriées dans Tableau 4, la commande l’affiche show comme « inconnue ». Vous pouvez afficher le dernier port enregistré TLV reçu à 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

Junos OS enregistre le dernier TLV d’état du port transmis d’un meP local. Si la transmission de l’TLV d’état du port n’a pas été activée, la show commande affiche « aucun ». Vous pouvez afficher le dernier TLV d’état des ports 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 :

TLV d’état de l’interface

Le TLV d’état de l’interface indique l’état de l’interface sur laquelle le MEP transmettant le CCM est configuré, ou l’interface inférieure suivante dans la RFC 2863 IF-MIB de l’IETF. Le format de cette TLV est affiché dans Tableau 5. Les valeurs énumérées sont indiquées dans la section Tableau 6.

Tableau 5 : Format TLV statut de l’interface

Paramètre

Octet (séquence)

Type = 4

1

Length

2–3

Valeur (Voir Tableau 6)

4

Tableau 6 : Valeurs TLV statut de l’interface

Mnémonique

Statut de l’interface

Valeur

isUp

haut

1

isDown

en baisse

2

est le test

Test

3

est à l’insu

Inconnu

4

estDormant

dormant

5

n’est pasprésenté

pasprésenté

6

estLowerLayerDown

lowerLayerDown

7

REMARQUE :

Lorsque l’état opérationnel d’une interface logique passe de l’état descendant (valeur d’état 2) à l’état descendant de la couche inférieure (valeur d’état de 7) et vice versa, le piège SNMP LinkDown n’est pas généré. Par exemple, si vous configurez une offre d’interface Ethernet agrégée à l’aide d’une balise VLAN et ajoutez une interface physique qui est dans l’état opérationnel de l’offre, l’état opérationnel de l’offre d’interface logique Ethernet agrégée à ce point est inférieure (7). Si vous mettez le MIC associé à l’interface hors ligne, le piège LinkDown n’est pas généré lorsque l’interface logique passe de l’état descendant de la couche inférieure à l’état descendant.

De même, prenons un autre exemple de scénario dans lequel une interface physique est ajoutée à un offre Ethernet agrégée avec un balisage VLAN et 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 passe à la baisse. Si vous désactivez l’interface physique qui fait partie de l’offre Ethernet agrégée, l’état opérationnel de l’interface logique Ethernet agrégée reste en panne. Si vous réenablez l’interface logique Ethernet agrégée, le statut opérationnel de celle-ci passe de la couche inférieure vers le bas. Le piège SNMP LinkDown n’est pas généré à ce stade.

Configuration de l’état de l’interface TLV

Junos OS prend en charge la configuration du TLV d’état de l’interface, ce qui permet aux opérateurs de contrôler la transmission de cette TLV dans les PDU CCM par le biais d’une configuration au niveau de la vérification de la continuité.

REMARQUE :

Cette configuration n’est pas obligatoire par IEEE 802.1ag ; il est plutôt fourni pour donner plus de flexibilité à l’opérateur. Junos OS reçoit et traite les CCM avec le statut de l’interface TLV, quelle que soit cette configuration.

L’état TLV configuration de l’interface est indiqué ci-dessous :

REMARQUE :

Junos OS ne prend en charge la transmission que de trois valeurs possibles sur sept pour l’TLV d’état de l’interface. Les valeurs prises en charge sont 1, 2 et 7. Cependant, Junos OS est capable de recevoir n’importe quelle valeur pour l’état de l’interface TLV.

Afficher l’état de l’interface reçue TLV

Junos OS enregistre la dernière TLV d’état de l’interface reçue 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 Tableau 5, la show commande affiche « inconnu ».

Vous pouvez afficher cette dernière TLV statut de l’interface enregistrée à 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 du statut de l’interface transmise TLV

Junos OS enregistre le dernier statut de l’interface transmise TLV d’un meP local. Si la transmission de l’état de l’interface TLV n’a pas été activée, la show commande affiche « aucun ».

Vous pouvez afficher la dernière TLV d’état de l’interface transmise à 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

Junos OS fournit des informations sur le défaut d’état MAC, indiquant qu’un ou plusieurs des MEP distants signalent une défaillance dans son TLV d’état de port ou son TLV d’état de l’interface. Il indique « oui » si certains MEP distants signalent que leur interface n’est pas isUp (par exemple, au moins une interface MEP distante n’est pas disponible), ou si tous les MEP distants signalent un TLV d’état de port qui contient une valeur autre que psUp (par exemple, tous les MEP distants pont ports ne transfèrent pas de données). Vous pouvez utiliser deux show commandes pour afficher l’indication des défauts d’état 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 du profil d’action MEP distant

En fonction des valeurs des interface-status-tlv paquets CCM reçus et port-status-tlv des paquets CCM reçus, une action spécifique, telle que interface-down, peut être prise à l’aide des action-profile options. Il est possible de configurer plusieurs profils d’action sur le routeur, mais un seul profil d’action peut être assigné à un MEP distant.

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

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

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

Surveillance d’un profil d’action meP distant

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

show oam connectivité Ethernet-fault- gestion mep-database remote-mep (Événement du profil d’action)

Configuration de l’ID de châssis TLV

Dans les versions 16.1R2 et ultérieures, vous pouvez configurer Junos OS pour envoyer l’ID de l’expéditeur TLV avec les paquets. L’ID de l’expéditeur TLV est un TLV optionnel envoyé dans les messages de contrôle de continuité (CCM), les messages de bouclage et les messages de suivi de liaison (LTM), comme spécifié dans la norme IEEE 802.1ag. L’ID de l’expéditeur TLV contient l’ID du 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 length TLV indique si le TLV contient ou non les informations d’IDENTIFICATION du châssis. Les valeurs possibles pour le length champ sont zéro (0) ou n’importe quel nombre valide, ce qui indique l’absence ou la présence d’informations d’ID de châssis dans le TLV, respectivement.

Vous pouvez activer Junos OS pour envoyer l’ID de l’expéditeur TLV au niveau mondial à l’aide de la set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlv commande. Si l’ID de l’expéditeur TLV est configuré au niveau global, 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 de l’expéditeur TLV aux 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].

L’ID de l’expéditeur TLV configuration au niveau de l’association de maintenance prime sur la configuration globale.

REMARQUE :

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

Configuration du traitement des messages MAC Flush en mode CET

En mode de transport Ethernet opérateur (CET), les routeurs MX Series sont utilisés comme routeurs de périphérie fournisseur (PE), tandis que les commutateurs Ethernet opérateur A2200 Nokia Siemens Networks (appelés équipements E-domain) qui exécutent des protocoles standard sont utilisés côté accès. Sur les routeurs MX Series, les pseudowires VPLS sont configurés dynamiquement via le protocole de distribution d’étiquettes (LDP). Sur les équipements E-domain, les modifications de topologie sont détectées grâce à des sessions de gestion des pannes de connectivité (CFM) exécutées entre les équipements E-domain et les routeurs PE MX Series. Les routeurs PE MX Series peuvent réduire l’interface Ethernet opérateur en cas de perte de connectivité CFM. Cela déclenche une rinçage MAC local ainsi qu’une notification de rinçage MAC T-LDP qui est envoyée vers les PE MX Series distants pour déclencher une rinçage MAC dessus.

En mode inter-op CET, les routeurs MX Series doivent interagir avec les équipements d’accès Ethernet opérateur Ax100 de Nokia Siemens Networks (appelés équipements a-domaine) qui exécutent des protocoles hérités. Les équipements Nokia Siemens Networks A4100 et A8100 agissent comme un intermédiaire entre les routeurs PE MX Series et les équipements de domaine A. Ces équipements intermédiaires exécutent des procédures de fonction d’interworking (IWF) afin que des sessions de gestion de l’administration des opérations (OAM) puissent être exécutées entre les routeurs MX Series et les équipements de domaine A. Il n’y a pas de pseudowires VPLS entre les routeurs PE MX Series et les équipements intermédiaires Nokia Siemens Networks A4100 et A8100, il n’y a donc pas de protocole LDP s’exécutant entre les routeurs PE pour envoyer des notifications de changement de topologie. Afin de communiquer les changements de topologie, les routeurs MX Series peuvent déclencher un rinçage MAC et le propager dans le cœur. Les routeurs MX Series peuvent utiliser des profils d’action basés sur l’événement TLV de la valeur de type de protection de la connexion. Le profil d’action réduit l’interface logique de périphérie opérateur dans les routeurs PE MX Series, ce qui déclenchera une rinçage MAC locale et propagera également le changement de topologie au cœur à l’aide de la notification LDP.

Pour VPLS, aucune connectivité de bout en bout n’est surveillée. Les anneaux d’accès sont surveillés de manière indépendante en exécutant CFM sur plusieurs points de terminaison (MEP) sur les chemins de travail et de protection de chacun des services entre les équipements E-domain et les routeurs PE MX Series, et entre les équipements du domaine A 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 Nokia Siemens Networks Ax200 effectuent un basculement vers le chemin de protection, déclenchant une notification de changement de topologie (sous la forme de TLV transportées dans CCM) à envoyer sur le chemin actif.

Figure 1 : Topologie à double homéologie CETTopologie à double homéologie CET

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

Une rinçage MAC se produit lorsque la session CFM qui surveille le chemin de travail détecte que le trafic de service a migré vers le chemin de protection ou lorsque la session CFM qui surveille le chemin de protection détecte que le trafic de service a migré vers le chemin de travail.

Figure 2 : Topologie à double connexion CETTopologie à double connexion CET

Figure 2 décrit la topologie en double connexion sur les routeurs PE MX Series connectés au domaine A. Le mécanisme de rinçage MAC utilisé dans ce cas est également le même que celui utilisé pour le domaine A dans le scénario dual homed (Figure 1). Toutefois, dans ce cas, les deux sessions CFM sont hébergées par un seul routeur PE MX Series. Lorsque l’Ax100 du domaine A détecte des changements de topologie, le routeur MX Series PE reçoit la protection de la connexion TLV dans le message CCM pour les chemins de travail et de protection, avec la valeur « Protection-in-use » indiquant le chemin actif. En fonction de l’événement généré pour la session CFM, le routeur MX Series PE mettra en panne l’interface appropriée, ce qui déclenchera une chasse d’eau MAC locale.

Configuration d’un profil d’action TLV protection de connexion

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

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

Exemple : Configuration d’un profil d’action basé sur des TLV de protection de connexion

Cet exemple montre comment configurer un profil d’action en fonction du TLV de protection de connexion afin de déclencher des rinçages MAC en fonction des changements de topologie dans 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 utilisant des routeurs PE MX Series est illustrée dans Figure 3

topologie

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

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

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

  • E-domain : commutateurs Ethernet opérateur Nokia Siemens Networks qui exécutent des protocoles standard et sont utilisés côté accès.

  • A-domain : commutateurs Ethernet opérateur Nokia Siemens Networks qui exécutent des protocoles hérités.

Configuration

Procédure

Procédure étape par étape

Pour configurer un profil d’action en fonction de la protection de connexion TLV, préformez les tâches suivantes :

  1. Configurer un profil d’action

  2. Si la TLV de protection de connexion est reçue avec la valeur « Protection en cours d’utilisation » de SET, alors la protection de connexion TLV doit utiliser le chemin de protection

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

  4. Configurer le profil d’action pour réduire l’interface

Résultats

Vérifiez les résultats de la configuration

Tableau de l'historique des versions
Version
Description
17.3R1
À partir de la version 17.3R1 de Junos OS, vous pouvez activer la 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 du client lorsque l’équipement de périphérie du client n’est pas un équipement Juniper à l’aide du bit RDI (Remote Defect Indication).
16.1
Dans les versions 16.1R2 et ultérieures, vous pouvez configurer Junos OS pour envoyer l’ID de l’expéditeur TLV avec les paquets.