Surveillance CFM entre les équipements CE et PE
Utilisez ce sujet pour mieux comprendre la surveillance CFM entre les équipements de périphérie du fournisseur et les équipements de périphérie des clients lorsque l’équipement de périphérie du client n’est pas Juniper périphérique. Vous pouvez également comprendre comment les téléviseurs TLV d’état de l’interface, les VLV sur l’état des ports, les systèmes d’ID de châssis et les systèmes de protection des connexions TLV contribuent à surveiller votre réseau.
Notification asynchrone du profil d’action CFM
SUMMARY La notification asynchrone pilotée par CFM permet la synchronisation de l’état des liaisons entre deux équipements CE connectés entre eux par le biais d’une pseudo-connexion filaire provenant de leurs équipements PE respectifs Il émule le scénario comme si deux équipements CE sont directement connectés. CFM fournit une signalisation de bout en bout même si les pe1 et PE2 ne sont pas connectés par un seul réseau, mais par un ensemble de réseaux.
Connectivité de couche 2 entre PE1 et PE2
La Figure 1 est un exemple de déploiement dans lequel il est possible d’utiliser une notification asynchrone basée sur la technologie CFM pour synchroniser l’état des liaisons entre les niveaux CE1 et CE2. Les deux exigences suivantes peuvent être satisfaites avec la configuration de la notification asynchrone.
-
Lorsque la liaison entre PE2 et CE2 passe en panne, la liaison entre le PE1 et le CE1 s’en fait également baisser. Une fois la liaison rétablie, elle doit également restaurer l’état de la liaison PE1 vers CE1. Le changement d’état de la liaison PE1 vers CE1 doit fonctionner de la même manière.
-
En cas de problème de connectivité entre le PE1 et le PE2, il déclenche une liaison entre le PE1 et le CE1 et le PE2 vers le CE2. Si l’état de la connexion est rétabli, il doit restaurer l’état de la liaison aux deux extrémités.
Voir également
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.
See Also
Compréhension de la surveillance CFM entre les équipements CE et PE
Vous pouvez activer une surveillance de la gestion des pannes de connectivité (CFM) entre les équipements de périphérie du fournisseur et les équipements de périphérie des clients lorsque l’équipement de périphérie du client n’est pas Juniper périphérique. Lorsque l’interface est down, CFM propage l’état de l’interface dans les messages CC. Le message CC informe l’équipement de périphérie du client que l’équipement de périphérie du fournisseur est en panne.
Vous pouvez configurer la surveillance CFM en utilisant l’une des deux options suivantes:
TLV d’état d’interface (type, longueur et valeur): vous pouvez activer la gestion des pannes de connectivité (CFM) entre les équipements de périphérie du fournisseur et les équipements de périphérie du client lorsque l’équipement de périphérie du client n’est pas un équipement Juniper en utilisant Interface Status TLV. Lorsque l’interface est down, CFM propage l’état de l’interface à l’aide de la technologie TLV d’état de l’interface. L’état de l’interface TLV indique l’état de l’interface sur laquelle le MEP transmet le CCM ou l’interface inférieure suivante dans le IETF RFC 2863 IF-MIB. Ainsi, l’équipement de périphérie du client est conscient que l’équipement de périphérie du fournisseur est en panne. Pour configurer la surveillance CFM à l’aide de interface status TLV, utilisez
interface-status-tlvl’instruction au niveau[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-checkde la hiérarchie. Il s’agit de l’option standard.RDI (Indication de défaillance à distance): à partir du 17.3R1 de publication Junos OS, vous pouvez surveiller les pannes de connectivité entre les équipements de périphérie du fournisseur et les équipements de périphérie du client lorsque l’équipement de périphérie du client n’est pas un équipement Juniper en utilisant le bit de indication de défaillance à distance (RDI). Lorsque vous activez la surveillance CFM, CFM propage l’état de l’équipement de périphérie du fournisseur via le bit de indication de défaillance à distance (RDI) dans les messages CC. Ainsi, l’équipement de périphérie du client est conscient que l’équipement de périphérie du fournisseur est en panne. Le bit RDI est autorisé lorsque le service est en arrière. Pour configurer la surveillance CFM à l’aide du bit RDI, utilisez
interface-status-send-rdil’instruction au niveau[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-checkde la hiérarchie. Cette option est requise si l’équipement de périphérie du client ne prend pas en charge la technologie TLV état d’interface.
Lorsque l’interface est configurée pour CCC et que vous avez configuré RDI, un bit RDI est envoyé. CFM ne surveille pas l’état de l’interface. Si la panne CCC est définie lorsque l’interface n’est pas en veille, un bit RDI est envoyé avec les messages CC si vous avez configuré RDI.
- Cas d’utilisation de multi-homing actif unique à l’aide du bit RDI
- Multihoming actif/actif Cas d’utilisation à l’aide du bit RDI
Cas d’utilisation de multi-homing actif unique à l’aide du bit RDI
Prenons la topologie suivante: deux équipements de périphérie fournisseurs (PE1 et PE2) et deux équipements de périphérie clients (CE1 et CE2). LE PE1 est en état actif alors que le PE2 est en veille. CFM down MEP est configuré entre le PE et le CE. CFM détecte que la CCC est down et que le CFM vers le bas du MEP est configuré, les messages CC générés ont le bit RDI. Les messages CC de PE2 au CE2 sont placés sur le bit RDI pour indiquer l’état bloqué. Lorsque PE2 devient actif, le CCM down est autorisé et le bit RDI est autorisé à partir des messages CC suivants.
Multihoming actif/actif Cas d’utilisation à l’aide du bit RDI
Prenons la topologie dans laquelle se trouve deux équipements de périphérie fournisseurs (PE1 et PE2) et deux équipements de périphérie clients (CE1 et CE2). LE PE1 est en état actif alors que le PE2 est en veille. Si le CFM down MEP n’est pas configuré entre le PE et le CE pour surveiller la connectivité des liaisons, les messages CC générés n’ont pas le bit RDI. CFM down MEP est configuré entre le PE et le CE. CFM détecte que la CCC est down et que le CFM vers le bas du MEP est configuré, les messages CC générés ont le bit RDI. Les messages CC de PE2 au CE2 sont placés sur le bit RDI pour indiquer l’état bloqué. Lorsque PE2 devient actif, le CCM down est autorisé et le bit RDI est autorisé à partir des messages CC suivants.
Voir également
Configuration de l’état des ports TLV et état de l’interface TLV
- Présentation des VTT
- Divers téléviseurs pour PDUS CFM
- Prise en charge de téléviseurs supplémentaires en option
- Défauts d’état MAC
- Configuration de la prise en charge du profil d’action des meP distants
- Surveillance d’un profil d’action du MEP à distance
Présentation des VTT
Le type, la longueur et la valeur (TV) sont décrits dans la norme IEEE 802.1ag pour CFM comme méthode d’encodage des informations de longueur variable et/ou facultatives dans un PDU. Les VTT ne sont pas alignés sur un mot particulier ou une limite octet. Les VTL se suivent sans aucune rempage entre eux.
Tableau 1 affiche le format TLV et indique s’il est requis ou facultatif.
Paramètre |
Octet (séquence) |
Description |
|---|---|---|
Type |
1 |
Obligatoire. Si 0, aucun champ Longueur ou valeur ne s’en suit. Si ce n’est pas 0, le champ Longueur suit au moins le champ Type. |
Longueur |
2–3 |
Requis si le champ Type n’est pas 0. Non présent si le champ type est 0. Les 16 bits du champ Longueur indiquent la taille, dans les octets, du champ Valeur. 0 dans le champ Longueur indique qu’il n’y a pas de champ de valeur. |
Valeur |
4 |
Longueur spécifiée par le champ Longueur. Optionnel. Non présent si le champ Type est 0 ou si le champ de longueur est 0. |
Divers téléviseurs pour PDUS CFM
Tableau 2 affiche un ensemble de VTV définis par IEEE 802.1ag pour différents types de CFM PDU. Chaque TLV peut être identifié par la valeur unique attribuée à son champ type. Certaines valeurs de champ de type sont réservées.
TLV ou organisation |
Type de champ |
|---|---|
Fin du TLV |
0 |
ID expéditeur TLV |
1 |
État des ports TLV |
2 |
Lv des données |
3 |
État de l’interface TLV |
4 |
Réponse TLV entrée |
5 |
Réponse TLV sortie |
6 |
Identifiant de sortie LTM TLV |
7 |
Identifiant de sortie LTR TLV |
8 |
Réservé au IEEE 802.1 |
Entre 9 et 30 |
TLV spécifiques à l’entreprise |
31 |
Définition de l’ITU-T Y.1731 |
Entre 32 et 63 |
Réservé au IEEE 802.1 |
Entre 64 et 255 |
Chaque TLV n’est pas applicable à tous les types de PDUS CFM.
VTC applicables aux messages CCM (Continuity Check):
Fin du TLV
ID expéditeur TLV
État des ports TLV
État de l’interface TLV
TLV spécifiques à l’entreprise
Téléviseurs LBM (Loopback Message):
Fin du TLV
ID expéditeur TLV
Lv des données
TLV spécifiques à l’entreprise
TLV applicables pour la réponse en boucle (LBR):
Fin du TLV
ID expéditeur TLV
Lv des données
TLV spécifiques à l’entreprise
VLAN applicables aux messages de liaison (LTM):
Fin du TLV
Identifiant de sortie LTM TLV
ID expéditeur TLV
TLV spécifiques à l’entreprise
VLAN applicables pour la réponse par liaison (LTR):
Fin du TLV
Identifiant de sortie LTR TLV
Réponse TLV entrée
Réponse TLV sortie
ID expéditeur TLV
TLV spécifiques à l’entreprise
Les TV suivants sont actuellement pris en charge dans les PDUS CFM applicables:
Fin du TLV
Réponse TLV entrée
Réponse TLV sortie
Identifiant de sortie LTR TLV
Identifiant de sortie LTM TLV
Lv des données
Prise en charge de téléviseurs supplémentaires en option
Les TLV supplémentaires supplémentaires suivants sont pris en charge:
État des ports TLV
État de l’interface TLV
MX Series la configuration de l’état des ports TLV et de l’état de l’interface TLV. La configuration du TLV d’état du port permet à l’opérateur de contrôler la transmission de TLV d’état de port dans des PDUS CFM.
Bien que les déclarations de configuration TLV d’état de port soient visibles dans le CLI sur les routeurs M120 et M320, il n’est pas possible de configurer TLV d’état de port sur ces systèmes. La fonction TLV d’état des ports peut être activée sur une interface MEP uniquement s’il s’agit d’une interface logique de pontage, ce qui n’est pas possible sur ces systèmes.
Pour plus d’informations sur la configuration, consultez les sections suivantes:
État des ports TLV
L’état du port TLV indique la capacité du port de pont sur lequel réside le MEP transmis de transmettre des données ordinaires, quel que soit le statut de l’MAC. La valeur de ce TLV est motivée par la variable enableRmepDefect MEP, comme illustré dans Tableau 4 . Le format de cette TLV est indiqué dans Tableau 3 .
Tout changement de valeur des TLV d’état des ports déclenche une transmission supplémentaire de ces ports de pontage de M CCM meP.
Paramètre |
Octet (séquence) |
|---|---|
Type = 2 |
1 |
Longueur |
2–3 |
Valeur Tableau 4 (voir) |
4 |
Mnémonique |
Des données ordinaires transitent librement à travers le port |
Valeur |
|---|---|---|
ps Blocage |
non: |
1 |
psUp |
Oui: |
2 |
La variable MEP est une variable booléen indiquant si des trames sur l’instance de service surveillés par les associations de maintenance sont activées par le protocole Spanning Tree et la gestion de la topologie VLAN pour traverser ce port de enableRmepDefect pontage. La valeur de ces valeurs est définie selon la valeur réelle des valeurs ci-après:
Le port de pont est placé dans un état où le trafic peut le passer.
Le port de pont exécute plusieurs instances du Spanning Tree.
L’interface MEP n’est pas associée à un domaine de pontage.
- Configuration de l’état des ports TLV
- Affichage dulv d’état du port reçu
- Affichage de l’état des ports transmis TLV
Configuration de l’état des ports TLV
Junos OS configuration des TLV d’état des ports, vous permet de contrôler la transmission de celvère dans des PDUS CCM. Le Junos OS fournit cette configuration au niveau de vérification de la continuité. Par défaut, le CCM n’inclut pas le TLV d’état du port. Pour configurer le TLV d’état du port, utilisez port-status-tlv l’instruction au niveau [edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check] de la hiérarchie.
La configuration TLV d’état des ports n’est pas IEEE 802.1ag. Cette Junos OS pour offrir plus de flexibilité à l’opérateur. toutefois, il reçoit et traite les MCC avec un TLV d’état de port, indépendamment de cette configuration.
Voici un exemple des instructions de configuration suivantes:
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 maintenance-association n’est pas un pont type.
Si le MEP est configuré sur une interface physique.
Affichage dulv d’état du port reçu
La Junos OS enregistre le dernier TLV d’état de port reçu d’un MEP distant. Si la valeur d’état du port reçu ne correspond pas à l’une des valeurs standard répertoriées, la commande l’affiche Tableau 4show comme « inconnue ». Vous pouvez afficher le dernier TLV d’état des ports enregistré à l’aide de la show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier commande, comme dans l’exemple suivant:
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 des ports transmis TLV
Le Junos OS enregistre le dernier TLV sur l’état des ports transmis auprès d’un meP local. Si la transmission du TLV d’état du port n’a pas été activée, la commande show s’affiche « aucune ». Vous pouvez afficher le dernier TLV d’état des ports enregistrés à l’aide de la show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier commande, comme dans l’exemple suivant:
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
État de l’interface TLV
L’état de l’interface TLV indique l’état de l’interface sur laquelle le MEP transmet le CCM ou l’interface inférieure suivante dans le IETF RFC 2863 IF-MIB. Le format de cette TLV est indiqué dans Tableau 5 . Les valeurs indiquées sont affichées dans Tableau 6 .
Paramètre |
Octet (séquence) |
|---|---|
Type = 4 |
1 |
Longueur |
2–3 |
Valeur Tableau 6 (voir) |
4 |
Mnémonique |
État de l’interface |
Valeur |
|---|---|---|
fin de vie |
jusqu’à |
1 |
estdown |
vers le bas |
2 |
test |
test |
3 |
est Connu |
Inconnu |
4 |
isDormant |
en sommeil |
5 |
isNotPrésent |
sans déclaration |
6 |
isLowerLayerDown |
couche inférieure (lowerLayerDown) |
7 |
Lorsque le statut opérationnel d’une interface logique passe de l’état inférieur (valeur de 2) à l’état inférieur de la couche inférieure (valeur d’état de 7) et vice versa, le piège SNMP de linkdown n’est pas généré. Par exemple, si vous configurez une offre d’interface Ethernet agrégée avec une balise VLAN et ajoutez une interface physique de l’état opérationnel vers le bas à l’offre, l’état opérationnel de l’offre d’interface logique Ethernet agrégée à ce stade est inférieur à la couche inférieure (7). Si vous prenez le MIC associé à l’interface hors ligne, le piège de linkdown n’est pas généré lorsque l’interface logique passe de l’état inférieur à l’état inférieur.
De même, envisagez un autre scénario d’exemple dans lequel une interface physique est ajoutée à une offre Ethernet agrégée qui dispose du balisage VLAN et de l’interface logique Ethernet agrégée est désactivée. Lorsque l’interface logique est désactivée, l’état opérationnel de l’interface logique change de direction. Si vous désactivez l’interface physique faisant partie de l’offre Ethernet agrégée, l’état opérationnel de l’interface logique Ethernet agrégée reste en baisse. Si vous reenregisez l’interface logique Ethernet agrégée, son statut opérationnel sera réduit de couche inférieure à inférieure. Le piège SNMP de linkdown n’est pas généré à ce stade.
- Configuration de l’état de l’interface TLV
- Affichage dulv d’état de l’interface de réception
- Affichage de l’état de l’interface transmise TLV
Configuration de l’état de l’interface TLV
La Junos OS fournit une prise en charge de la configuration des TLV d’état des interfaces, ce qui permet aux opérateurs de contrôler la transmission de ce TLV dans des PDUS CCM par le biais d’une configuration au niveau de la vérification de continuité.
Cette configuration n’est pas obligatoire IEEE 802.1ag ; sont plutôt fournis pour offrir plus de flexibilité à l’opérateur. Le Junos OS reçoit et traite les MCC avec le TLV d’état de l’interface, indépendamment de cette configuration.
L’état de l’interface la configuration TLV est affichée ci-dessous:
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
}
}
}
}
}
}
}
Le Junos OS prend en charge la transmission de trois valeurs possibles sur sept seulement pour le TLV d’état d’interface. Les valeurs prise en charge sont 1, 2 et 7. Toutefois, le Junos OS peut recevoir une valeur quelconque pour le TLV état d’interface.
Affichage dulv d’état de l’interface de réception
La Junos OS enregistre le dernier TLV d’état d’interface reçu auprès du meP distant. Si la valeur d’état de l’interface reçue ne correspond pas à l’une des valeurs standard répertoriées dans la commande, la commande s’affiche Tableau 5show « inconnue ».
Vous pouvez afficher cette dernière interface enregistrée État TLV à l’aide de la show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier commande, comme dans l’exemple suivant:
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
La Junos OS enregistre le dernier TLV d’état d’interface transmis à partir d’un mep local. Si la transmission d’État d’interface TLV n’a pas été activée, la commande show affiche « aucune ».
Vous pouvez afficher le dernier TLV d’état d’interface transmis à l’aide de la show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier commande, comme dans l’exemple suivant:
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
Le Junos OS fournit des informations sur les défauts d’état MAC, ce qui indique qu’un ou plusieurs des meP distants signalent une défaillance de son service TLV d’état de port ou de l’état de l’interface TLV. Il indique « oui » si un meP distant signale que son interface n’est pas en cours de création (par exemple, si au moins une interface mep distante est indisponible), ou si tous les mep distants signalent un TLV d’état de port qui contient une valeur autre que la mise en service (par exemple, tous les ports de pontage distants ne sont pas des données de communication). Il est possible d’utiliser deux commandes pour afficher la indication de défauts de statut show MAC.
Utilisez la mep-database commande pour afficher les défauts d’état MAC:
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 interfaces commande pour afficher les défauts d’état 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 des meP distants
En fonction des valeurs des paquets CCM reçus et de ceux-ci, vous pouvez prendre des mesures spécifiques à l’aide des interface-status-tlvport-status-tlv options interface-downaction-profile proposées. Plusieurs profils d’action peuvent être configurés sur le routeur, mais un seul profil d’action peut être attribué à un MEP distant.
Le profil d’action peut être configuré avec au moins un événement pour déclencher l’action ; mais l’action s’enclenche en cas d’un de ces événements. Il n’est pas nécessaire que tous les événements configurés se produisent. action
Un profil d’action ne peut être appliqué qu’au niveau mep distant.
L’exemple suivant affiche une configuration de profil d’action avec des commentaires explicites ajoutés:
[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 du MEP à distance
Vous pouvez utiliser la commande pour afficher l’état du profil d’action d’un show oam ethernet connectivity-fault-management mep-database MEP distant, comme dans l’exemple suivant:
show oam ethernet connectivity-fault- management mep-database remote-mep (Événement du profil d’action)
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, vous pouvez configurer l’Junos OS pour envoyer l’ID TLV de l’expéditeur ainsi que les paquets. L’ID TLV de l’expéditeur est un service de recherche et de contrôle de continuité (TLV) en option qui est envoyé dans les messages de vérification de continuité, les messages de bouclisation et les messages de trace de liens (LTM), tels que spécifiés dans la norme IEEE 802.1ag. L’ID TLV de l’expéditeur contient l’ID de châssis, qui est l’adresse MAC unique basée sur CFM de l’équipement, et l’adresse IP de gestion, qui est une adresse IPv4 ou IPv6.
La valeur du champ dans le TLV indique si le TLV contient ou non les informations d’ID de length châssis. Les valeurs possibles pour le champ sont de zéro () ou n’importe quel numéro valide, ce qui indique l’absence ou la présence d’informations d’ID de châssis dans le length0 TLV, respectivement.
Vous pouvez activer la Junos OS’envoyer l’ID TLV de l’expéditeur au niveau mondial à l’aide de la set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlv commande. Si l’ID TLV de l’expéditeur est configuré au niveau mondial, le domaine de maintenance par défaut, l’association de maintenance et la demi-fonction MIP (maintenance association Intermediate Point) héritent de cette configuration.
Vous pouvez également configurer l’ID TLV de l’expéditeur selon les niveaux hiérarchiques suivants:
[edit protocols oam ethernet connectivity-fault-management].[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name maintenance-association maintenance-association-name continuity-check].
La configuration TLV de l’ID de l’expéditeur au niveau maintenance-association a priorité sur la configuration globale.
L’ID TLV de l’expéditeur est pris en charge uniquement pour les PDUS 802.1ag et n’est pas pris en charge pour les unités de données de protocole (PDUS) de surveillance des performances.
Voir également
Configuration du traitement des messages MAC en mode CET
En mode Transport Ethernet opérateur (CET), les routeurs MX Series sont utilisés comme routeurs de périphérie du fournisseur (PE) et Nokia Siemens Networks A2200 Carrier Commutateurs Ethernet (appelés équipements E-domain) qui exécutent des protocoles standard sont utilisés dans le côté accès. Sur les routeurs MX Series, les pseudowires VPLS sont configurés de manière dynamique via le protocole de distribution d’étiquettes (LDP). Sur les équipements E-domain, des modifications de topologie sont détectées via des sessions de gestion des défaillances de connectivité (CFM) s’exécutant entre les équipements E-domain et les routeurs MX SERIES PE. Les routeurs MX Series PE peuvent down l’interface Ethernet opérateur en cas de perte de connectivité CFM. Cela déclenche une couleur MAC locale ainsi qu’une notification d’origine MAC ciblée (T-LDP) qui est envoyée vers le PE MX Series distant pour déclencher une attaque MAC.
En mode interopérables CET, les routeurs MX Series doivent fonctionner de façon interopérable avec les équipements d’accès Ethernet opérateur Ax100 Carrier De Nokia Networks (appelés équipements À domaine) qui exécutent des protocoles hérités. Nokia Siemens Networks Les équipements A4100 et A8100 de Nokia Siemens Networks agissent comme un intermédiaire entre les routeurs MX Series PE et les équipements À domaine. Ces équipements intermédiaires exécutent des procédures de fonction d’interconnexion (IWF) afin de pouvoir exécuter des sessions de gestion de l’administration des opérations (OAM) entre les routeurs MX Series et les équipements A-domain. Il n’y a pas de pseudowire VPLS entre les routeurs MX Series PE et les équipements de niveau intermédiaire A4100 et A8100 de Nokia Siemens Networks. Il n’existe donc aucun protocole LDP s’exécutant entre les routeurs PE pour envoyer des notifications de modification de la topologie. Afin de communiquer les modifications de topologie, les routeurs MX Series peuvent déclencher une couleur MAC et la propager dans le centre. MX Series routeurs d’entreprise peuvent utiliser des profils d’action basés sur l’événement TLV (Connection Protection Type Length Value). Le profil d’action regroupe l’interface logique de périphérie opérateur dans les routeurs MX SERIES PE, qui déclenchent une couleur MAC locale et propagent la modification de topologie au cœur à l’aide d’une notification LDP.
VPLS ne surveille aucune connectivité de bout en bout. Les anneaux d’accès sont surveillés indépendamment en exécutant CFM vers le bas de plusieurs points de terminaux (MEP) sur les chemins de travail et de protection pour chacun des services entre les équipements E-domain et les routeurs MX Series PE, et entre les équipements A-domain et les routeurs PE MX Series l’IWF hébergé par les équipements Nokia Siemens Networks A-4100. En cas de défaillance de connectivité sur le chemin de travail, les équipements Ax200 de Nokia Siemens Networks effectuent un basculement vers le chemin de protection, en déclenchement d’une notification des changements de topologie (sous la forme de VTC transportés dans CCM) pour être envoyés sur le chemin actif.
Figure 1 décrit la double topologie d’accès sur MX Series PE connectés au domaine A. Lorsqu’un équipement d’un domaine déclenche un basculement, il commence à commuter le trafic de service vers le nouveau chemin actif. Cette modification est communiquée dans les unités de données de protocole HELLO envoyées par cet équipement de domaine sur les chemins de travail et de protection. Lorsque l’IWF dans le A4100 recieve ces PDUs HELLO, il les convertit en messages CCM standard et insère également un TLV de protection contre les connexions. Le champ « Protection à l’utilisation » du champ de protection des connexions TLV est encodé avec le chemin actuellement actif et est inclus dans le message CCM. Les messages de CCM sont reçus par MX Series PE via le spoke VLAN dans le A4100. Dans le scénario à double accueil ci-dessus, un routeur PE MX Series surveille le chemin de travail, et l’autre MX Series PE surveille le chemin de protection.
Une couleur MAC se produit lorsque la session CFM qui surveille le chemin de travail détecte que le trafic de service est passé au chemin de protection ou lorsque la session CFM qui surveille le chemin de protection détecte que le trafic du service est passé au chemin de travail.
Figure 2 décrit la double topologie connectée sur MX Series PE connectés au domaine A. Le mécanisme de couleur MAC utilisé dans ce cas est également le même que celui utilisé pour le domaine A dans le scénario double d’accueil (Figure 1). Toutefois, les deux sessions CFM sont hébergées par un seul routeur MX SERIES PE. Lorsque le routeur Ax100 dans l’environnement A détecte des changements sur la topologie, le routeur PE MX Series reçoit le message TLV de protection des connexions dans le message CCM concernant les chemins de travail et de protection avec la valeur de « Protection à l’utilisation » indiquant le chemin actif. En fonction de l’événement généré pour la session CFM, le routeur MX SERIES PE baisse l’interface appropriée et déclenche une couleur MAC locale.
Configuration d’un profil d’action TLV pour la protection des connexions
Un profil d’action peut être configuré pour effectuer l’action en fonction des valeurs des interface-downconnection-protection-tlv paquets CCM reçus.
L’exemple suivant affiche une configuration de profil d’action avec des commentaires explicites ajoutés:
[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 téléviseurs à ligne de protection des connexions
Cet exemple montre comment configurer un profil d’action basé sur le TLV de protection des connexions à des fins de déclenchement de couleurs MAC en fonction des changements de topologie d’un réseau CET.
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants:
Junos OS version 11.2 ou ultérieure
Un routeur PE MX Series
Présentation et topologie
La topologie physique d’un réseau CET à l’aide de routeurs PE MX Series est montrée dans Figure 3
Topologie
Les définitions suivantes décrivent le sens de l’abréviation et des termes utilisés dans Figure 3 .
Équipement de périphérie fournisseur (PE): un équipement ou un ensemble d’équipements, à la périphérie du réseau du fournisseur, qui présente la vue du site du client par le fournisseur.
E-domain— Nokia Siemens Networks Carrier Commutateurs Ethernet qui exécutent des protocoles standard et sont utilisés dans le côté accès.
Domaine --Nokia Siemens Networks Carrier Commutateurs Ethernet qui exécutent les protocoles hérités.
Configuration
Procédure
Procédure étape par étape
Pour configurer un profil d’action basé sur la protection des connexions TLV, préformez ces tâches:
Configurer un profil d’action
[edit protocols oam ethernet connectivity-fault-management] action-profile <tlv-action> { event {Si le TLV de protection des connexions reçoit la valeur SET « Protection-in-use », alors ce dernier doit utiliser le chemin de protection.
connection-protection-tlv <using-protection-path>;
Si la protection de connexion TLV est reçue avec une valeur « Protection-in-use » de RESET, alors la protection de connexion TLV doit utiliser le chemin de travail
connection-protection-tlv <using-working-path>; }
Configurez le profil d’action pour faire baisser l’interface
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;
}
}