Sur cette page
Configuration d’un profil d’action CFM vers Asyncronus Notification
Comprendre la surveillance CFM entre les dispositifs CE et PE
Configuration du TLV d’état du port et de l’état de l’interface
Configuration du traitement des messages de vidage MAC en mode CET
Exemple : Configuration d’un profil d’action basé sur les TLV de protection de connexion
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 comprendrez mieux comment les TLV d’état d’interface, d’état de port, d’ID de châssis et de protection de connexion contribuent à la surveillance de votre réseau.
Notification asynchrone de profil d’action CFM
SUMMARY La notification asynchrone pilotée par CFM permet la synchronisation de l’état de la liaison entre deux dispositifs CE connectés l’un à l’autre par le biais d’un pseudo-fil provenant de leurs périphériques PE respectifs Il émule le scénario comme si deux dispositifs 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 diminue, la liaison entre PE1 et CE1 diminue également. Lorsque la liaison est restaurée, elle doit également restaurer l’état de la liaison PE1 à CE1. Le changement d’état de la 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 vers CE1 et entre 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
Configuration d’un profil d’action CFM vers Asyncronus Notification
SUMMARY CFM UP-MEP sur PE1 à PE2, surveille la connectivité entre PE1 et PE2. L’utilisation interface-status-tlv de sur ces terminaux UP-MEP indique l’état de liaison entre PE1 vers CE1 vers PE2 et l’état de liaison entre PE2 vers CE2 vers PE1. Le profil d’action doit être configuré sur PE1 à PE2 pour générer des notifications asynchrones vers les périphériques CE respectifs. Il est déclenché lorsqu’une perte d’adjacence est détectée ou qu’une liaison descendante est détectée dans le interface-status-tlv.
Voir également
Comprendre la surveillance CFM entre les dispositifs 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 est 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 hors service.
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 est inactive, 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 sur laquelle le MEP transmettant le CCM est configuré, ou l’interface immédiatement inférieure dans l’IF-MIB IETF RFC 2863. Ainsi, l’équipement périphérique client sait que l’équipement périphérique du fournisseur est en panne. Pour configurer la surveillance CFM à l’aide de la TLV d’état de l’interface, utilisez l’instruction au niveau de la
interface-status-tlv[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-checkhiérarchie. Il s’agit de l’option standard.RDI (Remote Defect Indication) : à partir de Junos OS version 17.3R1, 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 bit RDI (Remote Defect Indication). Lorsque vous activez la surveillance CFM, CFM propage l’état de l’équipement périphérique fournisseur via le bit d’indication de défaut à distance (RDI) dans les messages CC. Ainsi, l’équipement périphérique client sait que l’équipement périphérique 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 l’interface est définie sur CCC down et que vous avez configuré RDI, le bit RDI est envoyé. CFM ne surveille pas l’état de l’interface. Si CCC down est défini alors que l’interface n’est pas en veille, le bit RDI est envoyé avec les messages CC si vous avez configuré RDI.
- Un seul cas d’utilisation de multihébergement actif utilisant le bit RDI
- Cas d’utilisation du multihébergement actif/actif avec un bit RDI
Un seul cas d’utilisation de multihébergement actif utilisant le bit RDI
Prenons l’exemple de la topologie suivante, dans laquelle il existe deux équipements de périphérie fournisseur (PE1 et PE2) et deux équipements de périphérie client (CE1 et CE2). PE1 est à l’état actif tandis que PE2 est à l’état veille. CFM vers le bas MEP est configuré entre le PE et le CE. CFM détecte que le CCC vers le bas MEP est configuré et parce que CFM vers le bas MEP est configuré, les messages CC générés ont le bit RDI. Le bit RDI des messages CC de PE2 à CE2 est défini pour indiquer l’état bloqué. Lorsque PE2 devient actif, CCM down est effacé et le bit RDI est effacé des messages CC suivants.
Cas d’utilisation du multihébergement actif/actif avec un bit RDI
Prenons l’exemple d’une topologie où il y a deux équipements de périphérie fournisseur (PE1 et PE2) et deux équipements de périphérie client (CE1 et CE2). PE1 est à l’état actif tandis que PE2 est à l’état veille. Si CFM down MEP 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. CFM vers le bas MEP est configuré entre le PE et le CE. CFM détecte que le CCC vers le bas MEP est configuré et parce que CFM vers le bas MEP est configuré, les messages CC générés ont le bit RDI. Le bit RDI des messages CC de PE2 à CE2 est défini pour indiquer l’état bloqué. Lorsque PE2 devient actif, CCM down est effacé et le bit RDI est effacé des messages CC suivants.
Voir également
Configuration du TLV d’état du port et de l’état de l’interface
- Vue d’ensemble des TLV
- Divers TLV pour les PDU CFM
- Prise en charge de TLV optionnels supplémentaires
- Défauts d’état MAC
- Configuration de 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 |
Obligatoire. S’il est égal à 0, aucun champ Longueur ou Valeur ne s’affiche. Si ce n’est pas 0, au moins le champ Longueur suit le champ Type. |
Longueur |
2–3 |
Obligatoire si le champ Type n’est pas égal à 0. Non présent si le champ Type est égal à 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 é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 de type. Certaines valeurs de champ de 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.
Bien que les instructions de configuration Port Status TLV soient visibles dans la CLI sur les routeurs M120 et M320, Port Status TLV ne peut pas être configuré sur ces systèmes. Le TLV d’état de port ne peut être activé sur une interface MEP que 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 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émonique |
données ordinaires transitant librement par le port |
Valeur |
|---|---|---|
psBloqué |
Non: |
1 |
psUp (en anglais seulement) |
Oui: |
2 |
La variable MEP est une variable enableRmepDefect booléenne indiquant si les trames de l’instance de service surveillées par les associations de maintenance si cette MEP 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 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.
- Configuration du TLV d’état du port
- Affichage du TLV d’état du port reçu
- Affichage du TLV d’état du port transmis
Configuration du 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 de ce 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 le fournit afin de donner plus de flexibilité à l’opérateur ; Cependant, il reçoit et traite les CCM avec un TLV d’état de port, quelle que soit cette 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 du TLV d’état du port reçu
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 du TLV d’état du port transmis
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 commande, comme dans l’exemple show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier 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émonique |
État de l’interface |
Valeur |
|---|---|---|
isUp (en anglais seulement) |
haut de page |
1 |
isDown |
vers le 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.
- Configuration du 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
Configuration du 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 commande, comme dans l’exemple show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier 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 commande, comme dans l’exemple show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier 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, indiquant qu’un ou plusieurs MEP distants signalent une défaillance de leur TLV d’état de port ou d’état d’interface. Il indique « oui » si un MEP distant signale que son 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 ports de pont MEP distants ne transfèrent pas de données). Il existe deux show commandes que vous pouvez utiliser pour afficher l’indication MAC Status Defects.
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
Configuration de la prise en charge du profil d’action MEP distant
En fonction des valeurs de 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 interface-status-tlvaction-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 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 se déclencher 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
Configuration de l’ID de châssis TLV
Dans la version 16.1R2 et les versions ultérieures, vous pouvez configurer Junos OS pour envoyer le TLV d’ID d’expéditeur avec les paquets. Le TLV d’ID d’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. L’ID d’expéditeur TLV 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 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 length TLV, respectivement.
Vous pouvez activer Junos OS pour envoyer le TLV d’ID d’expéditeur 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 d’expéditeur est configuré au niveau global, le domaine de maintenance par défaut, l’association de maintenance et la demi-fonction MIP (point intermédiaire d’association de maintenance) héritent de cette configuration.
Vous pouvez également configurer le TLV de l’ID d’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 au niveau de l’association de maintenance est prioritaire sur la configuration au niveau global.
Le TLV d’ID d’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 (PDU) du protocole de surveillance des performances.
Voir également
Configuration du 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.
Configuration d’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 : Configuration d’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 MX Series PE est illustrée à la Figure 3
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 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.