Surveillance CFM entre les dispositifs 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 client lorsque l’équipement de périphérie du client n’est pas un équipement Juniper. En outre, vous en apprendrez davantage sur la façon dont les TLV d’état d’interface, d’état de port, d’ID de châssis et de protection des connexions contribuent à la surveillance de votre réseau.
Notification asynchrone de profil d’action CFM
La notification asynchrone pilotée par CFM permet de synchroniser l’état de la liaison entre deux équipements CE connectés l’un à l’autre par l’intermédiaire d’un pseudo-fil provenant de leurs dispositifs PE respectifs. Il émule le scénario comme si deux appareils CE étaient 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. Les deux conditions suivantes peuvent être remplies avec la configuration de la notification asynchrone.
-
Lorsque la liaison entre PE2 et CE2 est défaillante, la liaison entre PE1 et CE1 diminue également. Lorsque la liaison est restaurée, elle restaurel’état de laliaison entre PE1 et CE1. Le changement d’état de liaison entre PE1 et CE1 devrait fonctionner de la même manière.
-
Lorsqu’il y a un problème de connectivité entre PE1 et PE2, cela déclenche une liaison descendante entre PE1 et CE1 et PE2 et CE2. Si l’état de la connexion est rétabli, il devrait restaurer l’état de la liaison aux deux extrémités.
Voir également
Configurer un profil d’action CFM vers Asyncronus Notification
CFM UP-MEP sur PE1 et PE2, surveille la connectivité entre PE1 et PE2. Le interface-status-tlv sur ces terminaux UP-MEP indique l’état de la liaison entre PE1, CE1et PE2, ainsi qu’entre PE2, CE2et PE1. Vous devez configurer le profil d’action sur PE1 à PE2 pour générer des notifications asynchrones vers les équipements CE respectifs. Le profil d’action déclenche ces notifications lorsque le système détecte une perte d’adjacence ou une condition de liaison dans le fichier . interface-status-tlv
Comprendre la surveillance CFM entre les équipements CE et PE
Vous pouvez activer la surveillance de la gestion des problèmes 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 tombe en panne, CFM propage l’état de l’interface dans les messages CC. Le message CC informe l’équipement périphérique client que l’équipement périphérique du fournisseur est en panne.
Vous pouvez configurer la surveillance CFM à l’aide de l’une des deux options suivantes :
Interface Status TLV (Type, Length, and Value) : vous pouvez activer la surveillance de la gestion des problèmes de connectivité (CFM) entre les équipements de périphérie du fournisseur et les équipements de périphérie client lorsque l’équipement de périphérie client n’est pas un équipement Juniper à l’aide du TLV d’état de l’interface. Lorsque l’interface tombe en panne, CFM propage l’état de l’interface à l’aide du TLV d’état de l’interface. Le TLV d’état de l’interface indique l’état de l’interface qui héberge le MEP transmettant le CCM, ou indique l’interface immédiatement inférieure dans l’IF-MIB IETF RFC 2863. Ainsi, l’équipement de périphérie du client apprend que l’équipement de périphérie du fournisseur est en panne. Pour configurer la surveillance CFM à l’aide de la TLV d’état de l’interface, utilisez l’instruction
interface-status-tlvau niveau de la[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-checkhiérarchie. Cette configuration est l’option standard.RDI (Remote Defect Indication) : 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 client lorsque l’équipement de périphérie client n’est pas un équipement Juniper à l’aide du bit RDI. Lorsque vous activez la surveillance CFM, CFM propage l’état de l’équipement de périphérie du fournisseur via le bit RDI des messages CC, ce qui informe l’équipement de périphérie client que l’équipement de périphérie du fournisseur est en panne. Le bit RDI est effacé lorsque le service est rétabli. Pour configurer la surveillance CFM à l’aide du bit RDI, utilisez l’instruction
interface-status-send-rdiau niveau de la[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-checkhiérarchie. Cette option est requise si l’équipement périphérique client ne prend pas en charge le TLV d’état de l’interface.
Lorsque vous définissez l’interface sur CCC down et que vous configurez RDI, l’appareil envoie le bit RDI. CFM ne surveille pas l’état de l’interface.
Si vous arrêtez CCC alors que l’interface n’est pas en veille et que vous configurez RDI, l’équipement inclut le bit RDI dans les messages CC.
- Un seul cas d’utilisation de multihébergement actif utilisant le bit RDI
- Cas d’usage du multihébergement actif/actif avec un bit RDI
Un seul cas d’utilisation de multihébergement actif utilisant le bit RDI
Considérons la topologie suivante, qui comprend deux équipements de périphérie fournisseur (PE1 et PE2) et deux équipements de périphérie client (CE1 et CE2). PE1 fonctionne à l’état actif, tandis que PE2 reste à l’état veille. Lorsque vous configurez CFM vers le bas MEP entre le PE et le CE, CFM détecte que le CCC est en panne et le système inclut le bit RDI dans les messages CC. Le bit RDI des messages CC de PE2 à CE2 est défini pour indiquer l’état bloqué. Lorsque PE2 devient actif, le système efface l’état CCM down et supprime le bit RDI des messages CC suivants.
Cas d’usage du multihébergement actif/actif avec un bit RDI
Considérons la topologie suivante, qui comprend deux équipements de périphérie fournisseur (PE1 et PE2) et deux équipements de périphérie client (CE1 et CE2). PE1 fonctionne à l’état actif, tandis que PE2 reste à l’état veille. Si vous ne configurez pas CFM down MEP entre le PE et le CE pour surveiller la connectivité de la liaison, le système n’inclut pas le bit RDI dans les messages CC. Lorsque vous configurez CFM vers le bas MEP entre le PE et le CE, CFM détecte que le CCC est en panne et le système inclut le bit RDI dans les messages CC. Le bit RDI des messages CC de PE2 à CE2 est défini pour indiquer l’état bloqué. Lorsque PE2 devient actif, le système efface l’état CCM down et supprime le bit RDI des messages CC suivants.
Voir également
Configure Port Status TLV et Interface Status TLV
- Vue d’ensemble des TLV
- Divers TLV pour les PDU CFM
- Prise en charge de TLV optionnels supplémentaires
- Défauts d’état MAC
- Configurer la prise en charge du profil d’action MEP distant
- Surveillance d’un profil d’action MEP distant
Vue d’ensemble des TLV
Le type, la longueur et la valeur (TLV) sont décrits dans la norme IEEE 802.1ag pour CFM en tant que méthode de codage d’informations de longueur variable et/ou facultatives dans une PDU. Les TLV ne sont pas alignées sur une limite particulière de mots ou d’octets. Les TLV se suivent sans rembourrage entre eux.
Tableau 1 affiche le format TLV et indique s’il est obligatoire ou facultatif.
Paramètre |
Octuor (séquence) |
Description |
|---|---|---|
Type |
1 |
Ce champ est obligatoire. Si la valeur est 0, aucun autre champ (Longueur ou Valeur) ne suit. Si la valeur n’est pas 0, le champ Longueur doit suivre. |
Longueur |
2–3 |
Ce champ n’est obligatoire que si le champ Type n’est pas égal à 0. Il n’est pas présent si le champ Type a la valeur 0. Les 16 bits du champ Longueur indiquent la taille, en octets, du champ Valeur. Une valeur de champ Longueur égale à 0 signifie qu’il n’y a pas de champ Valeur. |
Valeur |
4 |
La longueur de ce champ est spécifiée par le champ Longueur. Il est facultatif et ne sera pas présent si le champ Type est égal à 0 ou si le champ Longueur est égal à 0. |
Divers TLV pour les PDU CFM
Tableau 2 montre un ensemble de TLV définis par IEEE 802.1ag pour différents types de PDU CFM. Chaque TLV peut être identifié par la valeur unique attribuée à son champ Type. Certaines valeurs de champ Type sont réservées.
TLV ou Organisation |
Champ de type |
|---|---|
Fin de la TLV |
0 |
ID de l’expéditeur TLV |
1 |
TLV d’état du port |
2 |
TLV des données |
3 |
TLV d’état de l’interface |
4 |
Répondre Entrée TLV |
5 |
Répondre TLV de sortie |
6 |
TLV de l’identificateur de sortie LTM |
7 |
TLV de l’identificateur de sortie LTR |
8 |
Réservé à IEEE 802.1 |
9 à 30 |
TLV spécifique à l’organisation |
31 |
Défini par la norme UIT-T Y.1731 |
32 à 63 |
Réservé à IEEE 802.1 |
64 à 255 |
Tous les TLV ne sont pas applicables à tous les types de PDU CFM.
TLV applicables pour le message de contrôle de continuité (CCM) :
Fin de la TLV
ID de l’expéditeur TLV
TLV d’état du port
TLV d’état de l’interface
TLV spécifique à l’organisation
TLV applicables pour le message de bouclage (LBM) :
Fin de la TLV
ID de l’expéditeur TLV
TLV des données
TLV spécifique à l’organisation
TLV applicables pour la réponse de bouclage (LBR) :
Fin de la TLV
ID de l’expéditeur TLV
TLV des données
TLV spécifique à l’organisation
TLV applicables pour le message de suivi de liaison (LTM) :
Fin de la TLV
TLV de l’identificateur de sortie LTM
ID de l’expéditeur TLV
TLV spécifique à l’organisation
TLV applicables pour la réponse linktrace (LTR) :
Fin de la TLV
TLV de l’identificateur de sortie LTR
Répondre Entrée TLV
Répondre TLV de sortie
ID de l’expéditeur TLV
TLV spécifique à l’organisation
Les TLV suivantes sont actuellement prises en charge dans les PDU CFM applicables :
Fin de la TLV
Répondre Entrée TLV
Répondre TLV de sortie
TLV de l’identificateur de sortie LTR
TLV de l’identificateur de sortie LTM
TLV des données
Prise en charge de TLV optionnels supplémentaires
Les TLV optionnels supplémentaires suivants sont pris en charge :
TLV d’état du port
TLV d’état de l’interface
Les routeurs MX Series prennent en charge la configuration du TLV d’état de port et d’état d’interface. La configuration du TLV d’état du port permet à l’opérateur de contrôler la transmission du TLV de l’état du port dans les PDU CFM.
Pour plus d’informations sur la configuration, consultez les sections suivantes :
TLV d’état du port
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 l’état de l’adresse MAC. La valeur de cette TLV est déterminée par la variable enableRmepDefectMEP , comme indiqué dans Tableau 4. Le format de cette TLV est illustré en Tableau 3.
Toute modification de la valeur Port Status TLVs déclenche une transmission supplémentaire des CCM MEP des ports de ce pont.
Paramètre |
Octuor (Séquence) |
|---|---|
Type = 2 |
1 |
Longueur |
2–3 |
Valeur (Reportez-vous Tableau 4à ) |
4 |
Mnémotechnique |
données ordinaires transitant librement par le port |
Valeur |
|---|---|---|
psBloqué |
Non: |
1 |
psUp (en anglais seulement) |
Oui: |
2 |
La variable enableRmepDefect MEP est une variable booléenne. Il indique si les trames de l’instance de service surveillées par les associations de maintenance du MEP peuvent passer par le port de pont à l’aide du protocole Spanning Tree et de la gestion de la topologie VLAN. Il est défini sur TRUE si :
Le port de pont est défini dans un état où le trafic peut le traverser.
Le port de pont exécute plusieurs instances du Spanning Tree.
L’interface MEP n’est pas associée à un domaine de pontage.
- Configurer le TLV d’état du port
- Affichage de l’état du port reçu TLV
- Affichage de l’état du port transmis TLV
Configurer le TLV d’état du port
Junos OS prend en charge la configuration du TLV d’état du port, ce qui vous permet de contrôler la transmission du TLV dans les PDU CCM. Junos OS fournit cette configuration au niveau du contrôle de continuité. Par défaut, le CCM n’inclut pas le TLV d’état du port. Pour configurer le TLV Port Status, 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.
La configuration du TLV d’état du port n’est pas imposée par la norme IEEE 802.1ag. Le système d’exploitation Junos OS fournit cette configuration afin de donner plus de flexibilité à l’opérateur ; toutefois, il reçoit et traite les CCM avec une TLV d’état de port, quelle que soit la configuration.
Voici un exemple d’instructions de configuration :
protocols {
oam {
ethernet {
connectivity-fault-management {
maintenance-domain identifier {
level number;
maintenance-association identifier {
continuity-check {
interval number,
loss-threshold number;
hold-interval number;
port-status-tlv; # Sets Port Status TLV
}
}
}
}
}
}
}
Vous ne pouvez pas activer la transmission TLV d’état de port dans les deux cas suivants :
Si l’interface MEP sous l’association de maintenance n’est pas de type bridge.
Si le MEP est configuré sur une interface physique.
Affichage de l’état du port reçu TLV
Junos OS enregistre le dernier TLV d’état de port reçu à partir d’un MEP distant. Si la valeur d’état du port reçue ne correspond pas à l’une des valeurs standard répertoriées dans Tableau 4, la show commande l’affiche comme « inconnue ». Vous pouvez afficher le dernier TLV d’état de port reçu 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 :
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none # RX PORT STATUS
Interface status TLV: none
Affichage de l’état du port transmis TLV
Junos OS enregistre le dernier TLV d’état de port transmis à partir d’un MEP local. Si la transmission du TLV d’état du port n’a pas été activée, la show commande affiche « none ». Vous pouvez afficher le dernier TLV d’état de port transmis 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 :
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up # TX PORT STATUS
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: none
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 immédiatement inférieure dans l’IF-MIB IETF RFC 2863. Le format de cette TLV est illustré en Tableau 5. Les valeurs énumérées sont indiquées dans Tableau 6.
Paramètre |
Octuor (Séquence) |
|---|---|
Type = 4 |
1 |
Longueur |
2–3 |
Valeur (Reportez-vous Tableau 6à ) |
4 |
Mnémotechnique |
État de l’interface |
Valeur |
|---|---|---|
isUp (en anglais seulement) |
en haut |
1 |
isDown |
en bas |
2 |
isTesting |
test |
3 |
isUnknown |
inconnu |
4 |
isDormant |
dormant |
5 |
isNotPresent |
notPresent |
6 |
isLowerLayerDown |
lowerLayerDown |
7 |
Lorsque l’état opérationnel d’une interface logique passe de l’état inactif (valeur d’état de 2) à l’état d’arrêt de la couche inférieure (valeur d’état de 7) et vice versa, l’interruption SNMP LinkDown n’est pas générée. Par exemple, si vous configurez un bundle d’interfaces Ethernet agrégé avec une balise VLAN et que vous ajoutez une interface physique qui est à l’état opérationnel inactif au bundle, l’état opérationnel du bundle d’interfaces logiques Ethernet agrégé à ce point est la couche inférieure down (7). Si vous mettez hors ligne le MIC associé à l’interface, l’interruption LinkDown n’est pas générée lorsque l’interface logique passe de l’état d’arrêt de la couche inférieure à l’état d’arrêt.
De même, considérons un autre exemple de scénario dans lequel une interface physique est ajoutée à un bundle Ethernet agrégé doté d’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 de fonctionnement de l’interface logique passe à inactif. Si vous désactivez l’interface physique qui fait partie du bundle Ethernet agrégé, l’état opérationnel de l’interface logique Ethernet agrégée reste inactif. Si vous réactivez l’interface logique Ethernet agrégée, l’état de fonctionnement de celle-ci passe de la couche inférieure à la couche inférieure. L’interruption SNMP LinkDown n’est pas générée à ce stade.
- Configurer le TLV d’état de l’interface
- Affichage de l’état de l’interface reçue TLV
- Affichage de l’état de l’interface transmise TLV
Configurer le TLV d’état de l’interface
Junos OS prend en charge la configuration du TLV d’état d’interface, permettant ainsi aux opérateurs de contrôler la transmission de ce TLV dans les PDU CCM via la configuration au niveau du contrôle de continuité.
Cette configuration n’est pas prescrite par la norme 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 TLV d’état d’interface, quelle que soit cette configuration.
La configuration TLV d’état de l’interface est illustrée ci-dessous :
protocols {
oam {
ethernet {
connectivity-fault-management {
maintenance-domain identifier {
level number;
maintenance-association identifier {
continuity-check {
interval number;
loss-threshold number;
hold-interval number;
interface-status-tlv; # Sets the interface status TLV
}
}
}
}
}
}
}
Junos OS ne prend en charge la transmission que de trois des sept valeurs possibles pour le TLV d’état de l’interface. Les valeurs prises en charge sont 1, 2 et 7. Toutefois, Junos OS est capable de recevoir n’importe quelle valeur pour le TLV d’état de l’interface.
Affichage de l’état de l’interface reçue TLV
Junos OS enregistre le dernier TLV d’état d’interface reçu à partir 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 ce dernier TLV d’état d’interface 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 :
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: none # displays the Interface Status TLV state
Affichage de l’état de l’interface transmise TLV
Junos OS enregistre le dernier TLV d’état d’interface transmis à partir d’un MEP local. Si la transmission du TLV d’état de l’interface n’a pas été activée, la show commande affiche « none ».
Vous pouvez afficher le dernier TLV d’état de l’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 :
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: none
Défauts d’état MAC
Junos OS fournit des informations sur les défauts d’état MAC qui indiquent quand des MEP distants signalent des défaillances dans leur TLV d’état de port ou d’état d’interface. Le système indique « oui » si un ou plusieurs députés distants signalent que leur interface n’est pas « active » (par exemple, lorsque l’interface d’un député éloigné n’est pas disponible) ou si, tous les députés éloignés signalent un TLV d’état de port avec une valeur autre que « Actif » (par exemple, lorsque les ports de pont de tous les députés éloignés ne transfèrent pas de données). Vous pouvez afficher l’indication des défauts d’état MAC à l’aide de deux show commandes.
Utilisez la commande pour afficher les défauts d’état mep-database MAC :
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md6 maintenance-association ma6
Maintenance domain name: md6, Format: string, Level: 6
Maintenance association name: ma6, Format: string
Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames
MEP identifier: 500, Direction: down, MAC address: 00:05:85:73:7b:39
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: xe-5/0/0.0, Interface status: Active, Link status: Up
Defects:
Remote MEP not receiving CCM : no
Erroneous CCM received : no
Cross-connect CCM received : no
RDI sent by some MEP : no
Some remote MEP's MAC in error state : yes # MAC Status Defects yes/no
Statistics:
CCMs sent : 1658
CCMs received out of sequence : 0
LBMs sent : 0
Valid in-order LBRs received : 0
Valid out-of-order LBRs received : 0
LBRs received with corrupted data : 0
LBRs sent : 0
LTMs sent : 0
LTMs received : 0
LTRs sent : 0
LTRs received : 0
Sequence number of next LTM request : 0
1DMs sent : 0
Valid 1DMs received : 0
Invalid 1DMs received : 0
DMMs sent : 0
DMRs sent : 0
Valid DMRs received : 0
Invalid DMRs received : 0
Remote MEP count: 1
Identifier MAC address State Interface
200 00:05:85:73:39:4a ok xe-5/0/0.0
Utilisez la commande pour afficher les défauts d’état interfaces MAC :
user@host> show oam ethernet connectivity-fault-management interfaces detail
Interface name: xe-5/0/0.0, Interface status: Active, Link status: Up
Maintenance domain name: md6, Format: string, Level: 6
Maintenance association name: ma6, Format: string
Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames
Interface status TLV: up, Port status TLV: up
MEP identifier: 500, Direction: down, MAC address: 00:05:85:73:7b:39
MEP status: running
Defects:
Remote MEP not receiving CCM : no
Erroneous CCM received : no
Cross-connect CCM received : no
RDI sent by some MEP : no
Some remote MEP's MAC in error state : yes # MAC Status Defects yes/no
Statistics:
CCMs sent : 1328
CCMs received out of sequence : 0
LBMs sent : 0
Valid in-order LBRs received : 0
Valid out-of-order LBRs received : 0
LBRs received with corrupted data : 0
LBRs sent : 0
LTMs sent : 0
LTMs received : 0
LTRs sent : 0
LTRs received : 0
Sequence number of next LTM request : 0
1DMs sent : 0
Valid 1DMs received : 0
Invalid 1DMs received : 0
DMMs sent : 0
DMRs sent : 0
Valid DMRs received : 0
Invalid DMRs received : 0
Remote MEP count: 1
Identifier MAC address State Interface
200 00:05:85:73:39:4a ok xe-5/0/0.0
Configurer la prise en charge du profil d’action MEP distant
En fonction des valeurs de interface-status-tlv et port-status-tlv dans les paquets CCM reçus, une action spécifique, telle que interface-down, peut être effectuée à l’aide des action-profile options. 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 un ou plusieurs événements, et l’action se déclenche lorsque l’un de ces événements se produit. Il n’est pas nécessaire que tous les événements configurés se déclenchent action.
Un profil d’action ne peut être appliqué qu’au niveau MEP distant.
L’exemple suivant montre une configuration de profil d’action avec des commentaires explicatifs ajoutés :
[edit protocols oam ethernet connectivity-fault-management]
action-profile tlv-action {
event {
# If interface status tlv with value specified in the config is received
interface-status-tlv down|lower-layer-down;
# If port status tlv with value specified in the config is received
port-status-tlv blocked;
# If connectivity is lost to the peer */
adjacency-loss;
}
action {
# Bring the interface down */
interface-down;
}
default-actions interface-down;
}
# domains
maintenance-domain identifier {
# maintenance domain level (0-7)
level number;
# association
maintenance-association identifier {
mep identifier {
interface ge-x/y/z.w;
remote-mep identifier {
# Apply the action-profile for the remote MEP
action-profile tlv-action;
}
}
}
}
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 ethernet connectivity-fault- management mep-database remote-mep (événement de profil d’action)
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 remote-mep 200
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames
MEP identifier: 100, Direction: down, MAC address: 00:05:85:73:e8:ad
Auto-discovery: enabled, Priority: 0
Interface status TLV: none, Port status TLV: none # last status TLVs transmitted by the router
Interface name: ge-1/0/8.0, Interface status: Active, Link status: Up
Remote MEP identifier: 200, State: ok # displays the remote MEP name and state
MAC address: 00:05:85:73:96:1f, Type: Configured
Interface: ge-1/0/8.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: lower-layer-down
Action profile: juniper # displays remote MEP’s action profile identifier
Last event: Interface-status-tlv lower-layer-down # last remote MEP event
# to trigger action
Action: Interface-down, Time: 2009-03-27 14:25:10 PDT (00:00:02 ago)
# action occurrence time
Configurer l’ID de châssis TLV
Vous pouvez configurer Junos OS pour qu’il envoie l’ID de l’expéditeur TLV avec les paquets. Le TLV d’ID de l’expéditeur est un TLV facultatif qui est 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. Le TLV de l’ID de l’expéditeur contient l’ID de châssis, qui est l’adresse MAC unique basée sur CFM de l’appareil, et l’adresse IP de gestion, qui est une adresse IPv4 ou IPv6.
La valeur du length champ dans la TLV indique si la TLV contient ou non les informations d’ID de 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 global à l’aide de la set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlv commande. Si le TLV de l’ID de l’expéditeur est configuré au niveau global, le domaine de maintenance par défaut, l’association de maintenance et la demi-fonction de point intermédiaire d’association de maintenance (MIP) héritent de cette configuration.
Vous pouvez également configurer le TLV de l’ID de l’expéditeur 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]
La configuration TLV de l’ID de l’expéditeur maintenance-association au niveau est prioritaire sur la configuration au niveau global.
Le TLV de l’ID de l’expéditeur est pris en charge uniquement 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).
Voir également
Configurer le traitement des messages de vidage MAC en mode CET
En mode de transport Ethernet opérateur (CET), les routeurs MX Series sont utilisés comme routeurs PE (Provider Edge) et les commutateurs Ethernet opérateur A2200 Nokia Siemens Networks (appelés périphériques du domaine E) qui exécutent des protocoles basés sur des normes sont utilisés du côté de l’accès. Sur les routeurs MX Series, les pseudofils VPLS sont configurés dynamiquement via le protocole de distribution d’étiquettes (LDP). Sur les équipements du domaine E, les changements de topologie sont détectés par le biais de sessions de gestion des problèmes de connectivité (CFM) exécutées entre les équipements du domaine E et les routeurs PE MX Series. Les routeurs PE MX Series peuvent interrompre l’interface Ethernet opérateur en cas de perte de connectivité CFM. Cela déclenche un vidage MAC local ainsi qu’une notification de vidage MAC T-LDP (Targeted Label Distribution Protocol) qui est envoyée aux PE MX Series distants pour déclencher un vidage MAC sur eux.
En mode interopérabilité CET, les routeurs MX Series doivent interagir avec les périphériques d’accès Ethernet opérateur Ax100 de Nokia Siemens Networks (appelés périphériques de domaine A) qui exécutent des protocoles hérités. Les équipements Nokia Siemens Networks A4100 et A8100 servent d’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’interopérabilité (IWF) afin que des sessions OAM (Operations Administration Management) puissent être exécutées entre des routeurs MX Series et des équipements de domaine A. Il n’y a pas de pseudo-fils VPLS entre les routeurs PE MX Series et les équipements intermédiaires Nokia Siemens Networks A4100 et A8100, de sorte qu’aucun protocole LDP n’est en cours d’exécution entre les routeurs PE pour envoyer des notifications de changement de topologie. Pour communiquer les changements de topologie, les routeurs MX Series peuvent déclencher un vidage MAC et le propager dans le cur. Les routeurs MX Series peuvent utiliser des profils d’action basés sur l’événement TLV (Connection Protection Type Length Value). Le profil d’action interrompt l’interface logique de périphérie opérateur dans les routeurs PE MX Series, ce qui déclenche un vidage MAC local et propage également le changement de topologie vers le cur à 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 indépendamment en faisant passer CFM le long de plusieurs points d’extrémité (MEP) sur les chemins de travail et de protection pour chacun des services entre les périphériques du domaine E 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 périphériques Nokia Siemens Networks A-4100. Lorsqu’il y a une défaillance de connectivité sur le chemin de travail, les appareils 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és dans CCM) à envoyer sur le chemin actif.
Figure 1 décrit la topologie de double hébergement sur les routeurs PE MX Series connectés au domaine A. Lorsqu’un périphérique de domaine A déclenche un basculement, il commence à basculer le trafic de service vers le nouveau chemin actif. Ce changement est communiqué dans les unités de données de protocole (PDU) HELLO 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 un TLV de protection de connexion. Le champ « Protection en cours d’utilisation » du TLV de protection de connexion est codé 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 rayon VLAN de l’A4100. Dans le scénario de double hébergement ci-dessus, un routeur PE MX Series surveille le chemin de travail et l’autre routeur PE MX Series surveille le chemin de protection.
Un vidage MAC se produit lorsque la session CFM qui surveille le chemin de travail détecte que le trafic de service s’est déplacé vers le chemin de protection ou lorsque la session CFM qui surveille le chemin de protection détecte que le trafic de service s’est déplacé vers le chemin de travail.
Figure 2 décrit la double topologie attachée sur les routeurs PE MX Series connectés au domaine A. Le mécanisme de vidage MAC utilisé dans ce cas est également le même que celui utilisé pour le domaine A dans le scénario de double résidence (Figure 1). Toutefois, dans ce cas, les deux sessions CFM sont hébergées par un seul routeur MX Series PE. Lorsque Ax100 dans le domaine A détecte des changements de topologie, le routeur PE MX Series reçoit le TLV de protection de connexion dans le message CCM pour les chemins de travail et de protection avec la valeur « Protection en cours d’utilisation » indiquant quel chemin est le chemin actif. En fonction de l’événement généré pour la session CFM, le routeur PE MX Series arrêtera l’interface appropriée, ce qui déclenchera un vidage MAC local.
Configurer un profil d’action TLV de protection de connexion
Un profil d’action peut être configuré pour effectuer l’action interface-down en fonction des valeurs de connection-protection-tlv dans les paquets CCM reçus.
L’exemple suivant montre une configuration de profil d’action avec des commentaires explicatifs ajoutés :
[edit protocols oam ethernet connectivity-fault-management]
action-profile <tlv-action> {
event {
# If a connection protection TLV with a “Protection-in-use” value of SET is received */
connection-protection-tlv <using-protection-path>;
# If a connection protection TLV with a “Protection-in-use” value of RESET is received */
connection-protection-tlv <using-working-path>;
}
action {
# Bring the interface down */
interface-down;
}
}
Voir également
Exemple : Configurer un profil d’action basé sur les TLV de protection de connexion
Cet exemple montre comment configurer un profil d’action basé sur le TLV de protection de connexion dans le but de déclencher des vidages 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
Vue d’ensemble et topologie
La topologie physique d’un réseau CET utilisant des routeurs PE MX Series est illustrée à Figure 3la .
Topologie
Les définitions suivantes décrivent la signification de l’abréviation de l’appareil et des termes utilisés dans Figure 3.
Périphérique de périphérie du fournisseur (PE) : équipement ou ensemble d’appareils, à la périphérie du réseau du fournisseur qui présente la vue du fournisseur sur le site du client.
Domaine E : Commutateurs Ethernet opérateur Nokia Siemens Networks qui exécutent des protocoles standard et sont utilisés côté accès.
Domaine A : 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 basé sur le TLV de protection de connexion, effectuez les tâches suivantes :
Configurer un profil d’action
[edit protocols oam ethernet connectivity-fault-management] action-profile <tlv-action> { event { } }Si la TLV de protection de connexion est reçue avec une valeur « Protection en cours d’utilisation » de SET, la TLV de protection de connexion doit utiliser le chemin de protection
connection-protection-tlv <using-protection-path>;
Si la TLV de protection de connexion est reçue avec une valeur « Protection en cours d’utilisation » de RESET, alors la TLV de protection de connexion doit utiliser le chemin de travail
connection-protection-tlv <using-working-path>;
Configurer le profil d’action pour mettre l’interface hors service
action { /* Bring the interface down */ interface-down; }
Résultats
Vérifier les résultats de la configuration
[edit protocols oam ethernet connectivity-fault-management]
action-profile <tlv-action> {
event {
connection-protection-tlv <using-protection-path>;
connection-protection-tlv <using-working-path>;
}
action {
interface-down;
}
}
Tableau de l'historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.