Dépannage des défaillances PVC lors de l'utilisation des cellules OAM et de la gestion PVC

Introduction

Si un problème de communication se pose sur un PVC (aucun trafic allant d'une manière ou d'une autre), le circuit virtuel permanent (PVC) demeure sur les fin-périphériques. Par conséquent, en conduisant les entrées qui indiquaient ce PVC restez dans la table de routage pendant un certain temps et en conséquence, des paquets sera perdu. La solution au problème est d'employer le fonctionnement et entretien (OAM) pour détecter de telles pannes et pour permettre au PVC pour déconnecter si elle est perturbée le long de son chemin.

Vous pouvez visualiser une configuration d'échantillon sur utiliser OAM pour la gestion PVC en cliquant sur ici.

Avant de commencer

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Conditions préalables

Aucune condition préalable spécifique n'est requise pour ce document.

Composants utilisés

OAM et gestion PVC sont pris en charge depuis la version 11.1(22)CC de Cisco IOS® et dans la version 12.0 et ultérieures de Cisco IOS.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Diagramme du réseau

Ce document est basé sur l'installation suivante :

• 1/116 est le VPI/VCI alloué au circuit virtuel (circuit virtuel) sur le chemin complet.

• Les Commutateurs ATM sont le Cisco IOS courant 12.0. Les Commutateurs ATM ont été configurés pour envoyer le signal d'indication d'alarme/indicateur de défauts distant (AIS/RDI) sur la panne de lien, comme expliqué dans ce document.

• Vous pouvez produire des pannes en arrêtant (la sous) interface sur le Guilder et en observant ce qui se produit sur Bernard. Nous avons activé des horodateurs de service mettons au point la milliseconde date-heure dans les configurations pour le tout les met au point dans ce document. Ceci nous permet pour voir la période du chaque des événements dans la milliseconde.

Détecter des pannes

Nous considèrerons seulement des cellules F5 OAM (circuit virtuel de niveau) pour ce document puisque ce sont les seuls utilisés par des fin-périphériques de Cisco (Routeurs) pour détecter des pannes. Afin de détecter une panne le long du chemin PVC sur un fin-périphérique, OAM utilise ces cellules spécifiques :

• Cellules de bouclage

• Cellules du contrôle de continuité (cc)

• Cellules du signal d'indication d'alarme (AIS)

• Cellules distantes de l'indication de détection (RDI)

Il y a trois conditions pour déclarer un PVC :

• Le routeur reçoit un nombre configuré de réponses de bout en bout successives de cellule de bouclage F5 OAM.

• Le routeur ne reçoit pas des cellules F5-AIS pendant 3 secondes.

• Le routeur ne reçoit pas des cellules F5-RDI pendant 3 secondes.

La section suivante décrit ces cellules et sorties affichant leurs effets.

Cellules de bouclage OAM

À intervalles réguliers, les fin-périphériques (tels que des Routeurs) configurés pour OAM envoient les cellules de bouclage qui doivent être faites une boucle dans le réseau. Ce point de bouclage peut être l'ordinateur à l'extrémité du PVC (cellules de boucle locale de bout en bout) ou d'un matériel sur le chemin (cellules en segments mode bouclé).

Les identifiants dans la cellule de bouclage indiquent quels dispositifs devraient faire une boucle la cellule. Un périphérique de Cisco qui termine un circuit virtuel en recevant une telle cellule sur un PVC le fera une boucle même si il n'est pas configuré pour OAM. En outre, chacune de ces cellules contiendra un indicateur de « direction » (pour identifier si c'est une cellule de commande ou de réponse) et un numéro de séquence (appelé balise ou CTag de Correlation dans met au point). La cellule de bouclage de « commande » et la cellule de bouclage de « réponse » auront le même numéro de séquence.

Le diagramme suivant montre des cellules du bouclage (livre) :

Exemple de sortie de débogage

Les expositions suivantes met au point (mettez au point l'oam atmosphère) qui illustre les cellules de bouclage sur Bernard :

Mar 30 14:22:39.050: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:2 CTag:17128
Tries:0
Mar 30 14:22:39.050: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:42E9
Mar 30 14:22:39.050: ATM OAM LOOP(ATM2/0/0) I: VCD#4 VC 1/116 LoopInd:0CTag:42E9
Mar 30 14:22:48.958: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:2 CTag:17129
Tries:0
Mar 30 14:22:48.958: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:42EA
Mar 30 14:22:48.958: ATM OAM LOOP(ATM2/0/0) I: VCD#4 VC 1/116 LoopInd:0CTag:42EA

Commentaires sur l'exemple de sortie de débogage

• La première ligne indique que le temporisateur utilisé pour identifier quand une cellule de bouclage doit être émise sur la sous) interface a (a expiré.

• Une cellule de bouclage de commande est alors envoyée sur l'interface correspondante (la deuxième ligne du met au point). La valeur de CTag affichée sur cette ligne est la valeur hexadécimale de la première ligne CTag plus un.

• Une cellule de bouclage faite une boucle est alors reçue avec un LoopInd égal à zéro.

Remarque: LoopInd=1 indique qu'une cellule de commande et un LoopInd=0 indique une cellule de réponse (faite une boucle). LoopInd=1 n'affiche pas dans met au point, mais apparaîtrait sur un tracé de renifleur.

Exemple de sortie de débogage (si des cellules de bouclage sont perdues)

Considérez un périphérique (utilisant PVCs) configuré pour envoyer des cellules OAM et gestion PVC d'utilisation. Si ce matériel perd un certain nombre de cellules de bouclage, il met le PVC dans un état d'indisponibilité. Voyez que ce qui suit met au point :

Mar 30 14:48:31.704: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 
Status:2 CTag:17284
Tries:0
Mar 30 14:48:31.704: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:4385


At this point, the sub-interface corresponding to PVC 1/116 on Guilder is shut down


Mar 30 14:48:41.684: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:1 CTag:17285
Tries:0
Mar 30 14:48:41.684: atm_oam_setstate - VCD#4, VC 1/116: newstate = Down Retry <-no reply to the loopback cell just sent
Mar 30 14:48:41.684: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:4386
Mar 30 14:48:42.680: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:1 CTag:17286
Tries:1
Mar 30 14:48:42.680: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:4387
Mar 30 14:48:43.680: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:1 CTag:17287
Tries:2
Mar 30 14:48:43.680: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:4388
Mar 30 14:48:44.680: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:1 CTag:17288
Tries:3
Mar 30 14:48:44.680: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:4389
Mar 30 14:48:45.676: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:1 CTag:17289
Tries:4
Mar 30 14:48:45.676: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:438A
Mar 30 14:48:46.676: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:1 CTag:17290
Tries:5 <- the router makes 5 retries before declaring the PVC down
Mar 30 14:48:46.676: atm_oam_setstate - VCD#4, VC 1/116: newstate = Not Verified 
<-5 retries and no answers -> PVC declared down
Mar 30 14:48:46.676: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM2/0/0.116,changed state to down
Mar 30 14:48:46.676: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:438B

Vous pouvez configurer la quantité de cellules perdues requises pour mettre le PVC vers le bas. La commande suivante du show atm pvc vpi/vci explique le précédent met au point.

Bernard# sh atm pvc 1/116
ATM2/0/0.116: VCD: 4, VPI: 1, VCI: 116
UBR, PeakRate: 155000
AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0
OAM frequency: 10 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Sent
OAM VC state: Not Verified
ILMI VC state: Not Managed
VC is managed by OAM.
InARP frequency: 15 minutes(s)
InPkts: 4, OutPkts: 4, InBytes: 280, OutBytes: 300
InPRoc: 2, OutPRoc: 0, Broadcasts: 5
InFast: 0, OutFast: 0, InAS: 2, OutAS: 0
InPktDrops: 0, OutPktDrops: 364240961
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
Out CLP=1 Pkts: 0
OAM cells received: 9
F5 InEndloop: 9, F5 
InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0
F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0
OAM cells sent: 18
F5 OutEndloop: 18, F5 OutSegloop: 0, F5 OutRDI: 0
F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0
OAM cell drops: 0
Status: DOWN, State: NOT_VERIFIED

Comme vous pouvez voir, les bouclages F5 ont été envoyés, mais pas répondus (18 F5 OutEndloop mais seulement 9 F5 InEndloop ; donc, 9 cellules de bouclage faites une boucle par F5 ont été perdues.). Ceci a fait descendre le PVC (pendant que la gestion PVC est configurée). F5 OutEndloop représente le nombre de cellules de bouclage envoyées et F5 InEndloop représente le nombre de cellules de bouclage F5 reçues.

Comme vous pouvez également voir, les compteurs de cellules F4 OAM sont présents, mais rien n'est enregistré puisque seulement les cellules F5 sont considérées ici. De la sortie de commande show ci-dessus, d'autres informations intéressantes peuvent être collectées concernant des cellules de bouclage :

• Des cellules OAM sont envoyées toutes les 10 secondes indépendamment de si le PVC est en haut ou en bas.

• Si le PVC est en hausse mais l'autre extrémité ne répond pas, les essais de routeur pour envoyer le cellsevery OAM en second lieu jusqu'à ce qu'il reçoive une réponse ou jusqu'à ce que 5 cellules OAM n'ont pas été répondues. Alors le PVC descend (voyez met au point ci-dessus).

• Sur l'autre extrémité, si le PVC est en baisse et il reçoit soudainement une cellule faite une boucle valide, il essayera de renvoyer des cellules livre chaque seconde jusqu'à ce que 3 cellules faites une boucle valides de bouclages dans une ligne soient reçues. Alors le PVC montera de nouveau. Voyez que met au point ci-dessous.

Mar 31 12:40:10.154: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM2/0/0.116, changed state to down
Mar 31 12:40:20.074: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:1 CTag:25267
Tries:6
Mar 31 12:40:20.074: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:62B4
Mar 31 12:40:20.074: ATM OAM LOOP(ATM2/0/0) I: VCD#4 VC 1/116 LoopInd:0 CTag:62B4
Mar 31 12:40:20.074: atm_oam_setstate - VCD#4, VC 1/116: newstate = Up Retry 

! PVC was down and suddenly receives a valid response loopback cell

Mar 31 12:40:21.070: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:2 CTag:25268
Tries:0
Mar 31 12:40:21.070: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:62B5
Mar 31 12:40:21.070: ATM OAM LOOP(ATM2/0/0) I: VCD#4 VC 1/116 LoopInd:0 CTag:62B5 

! first looped LB cell

Mar 31 12:40:22.066: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:2 CTag:25269
Tries:0
Mar 31 12:40:22.066: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:62B6
Mar 31 12:40:22.066: ATM OAM LOOP(ATM2/0/0) I: VCD#4 VC 1/116 LoopInd:0 CTag:62B6 

! second looped LB cell in a row

Mar 31 12:40:23.062: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:2 CTag:25270
Tries:0
Mar 31 12:40:23.062: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:62B7
Mar 31 12:40:23.062: ATM OAM LOOP(ATM2/0/0) I: VCD#4 VC 1/116 LoopInd:0 CTag:62B7 

! third looped LB cell in a row

Mar 31 12:40:23.062: atm_oam_setstate - VCD#4, VC 1/116: newstate = Verified 

! PVC is declared up again

Mar 31 12:40:23.062: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM2/0 0.116, changed state to up

Comme vous pouvez voir, la sous-interface (par conséquent le PVC) a été évoquée de nouveau après la réception de trois cellules de bouclage valides de réponse dans une ligne.

Remarque: L'utilisateur peut configurer tous les paramètres décrits ci-dessus, aussi bien qu'utilise la commande du show atm pvc vpi/vci de vérifier les paramètres.

Signal d'indication d'alarme/indicateur de défauts distant (AIS/RDI)

À la découverte d'une panne, un périphérique configuré pour OAM envoie des trames AIS en aval et envoie des trames RDI en amont.

L'exemple suivant montre les cellules AIS et RDI. Supposez que le signal de Rx disparaît sur un commutateur. La panne dans ce cas s'appelle une perte de signal (visibilité directe). Le commutateur qui l'a détecté envoie un en aval AIS comparé à la panne et un en amont RDI comparée à la panne.

En recevant de telles cellules, un fin-périphérique configuré pour la gestion PVC réduit le PVC affecté. Ces des cellules AIS et RDI sont envoyées utilisant le même VPI/VCI que les cellules utilisateur sur le PVC. En outre, le périphérique envoie à ces cellules chaque seconde jusqu'à ce que la panne disparaisse.

Exemple de sortie de débogage

Vous pouvez détecter une panne de plusieurs manières :

• Un niveau plus bas OAM (F1 AIS, la perte de signal, et ainsi de suite) la signale.

• La réception d'un AIS ou d'un RDI le déclenche.

• Le périphérique ne reçoit plus des cellules cc.

Une cellule du contrôle de continuité (cc) est une cellule que les périphériques configurés pour OAM régulièrement envoient et les utilisent pour vérifier l'intégrité de « lien ». Les Routeurs de Cisco n'envoient pas ces cellules ainsi ils ne sont pas discutés ici. Pour plus d'informations sur des cellules OAM cc, référez-vous à ITU-T I.610.

Ce qui suit met au point affiche ce qui se produit sur un routeur configuré pour la gestion PVC à la réception d'une cellule AIS/RDI :

Mar 31 13:11:18.990: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:2 CTag:25470
Tries:0
Mar 31 13:11:18.990: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:637F
Mar 31 13:11:18.990: ATM OAM LOOP(ATM2/0/0) I: VCD#4 VC 1/116 LoopInd:0 CTag:637F

En ce moment, le PVC sur Bernard descend (l'interface principale sur le Guilder est arrêtée) :

Mar 31 13:11:28.894: ATM OAM(ATM2/0/0.116): Timer: VCD#4 VC 1/116 Status:2 CTag:25471
Tries:0
Mar 31 13:11:28.894: ATM OAM LOOP(ATM2/0/0.116) O: VCD#4 VC 1/116 CTag:6380
Mar 31 13:11:29.806: atm_oam_ais(ATM2/0/0): AIS signal, failure=0x6A, VC 1/116
Mar 31 13:11:29.806: atm_oam_setstate - VCD#4, VC 1/116: newstate = AIS/RDI
Mar 31 13:11:29.806: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM2/0/0.116, changed state to down
Mar 31 13:11:30.806: atm_oam_ais(ATM2/0/0): AIS signal, failure=0x6A, VC 1/116
Mar 31 13:11:31.806: atm_oam_ais(ATM2/0/0): AIS signal, failure=0x6A, VC 1/116
Mar 31 13:11:32.806: atm_oam_ais(ATM2/0/0): AIS signal, failure=0x6A, VC 1/116

Vous pouvez vérifier le nouvel état PVC avec la commande suivante :

Bernard# sh atm pvc 1/116
ATM2/0/0.116: VCD: 4, VPI: 1, VCI: 116
UBR, PeakRate: 155000
AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0
OAM frequency: 10 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Sent
OAM VC state: AIS/RDI
ILMI VC state: Not Managed
VC is managed by OAM.
InARP frequency: 15 minutes(s)
InPkts: 4, OutPkts: 2, InBytes: 140, OutBytes: 60
InPRoc: 0, OutPRoc: 0, Broadcasts: 0
InFast: 0, OutFast: 0, InAS: 4, OutAS: 2
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
Out CLP=1 Pkts: 0
OAM cells received: 14
F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 14,
F5 InRDI: 0
F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0
OAM cells sent: 15
F5 OutEndloop: 1, F5 OutSegloop: 0, F5 OutRDI: 14
F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0
OAM cell drops: 0
Status: DOWN, State: NOT_VERIFIED

Comme vous pouvez voir, le PVC est descendu parce qu'il a reçu un signal F5 AIS ou RDI (dans ce cas particulier un AIS). Vous pouvez également voir que le routeur a généré des cellules F5 RDI à la réception des cellules AIS F5.

L'exemple suivant montre l'activité sur les deux Commutateurs sur le chemin :

• Sur LS1010-1 :

  1d03h: % OAM Pkt Rcv
  1d03h: % Intf: 0/0/0 VPI: 1 VCI: 116 OAM: F5-END-LPBK 
  
  ! OAM LB cell
  
  1d03h: % OAM Pkt Sent
  1d03h: % Intf: 0/0/1 VPI: 1 VCI: 116 OAM: F5-END-LPBK 
  
  ! OAM LB cell
    

  En ce moment, le PVC va vers le bas sur le Guilder :

  1d03h: % OAM Pkt Rcv
  1d03h: % Intf: 0/0/1 VPI: 1 VCI: 116 OAM: F5-AIS 
  
  ! AIS cell sent downstream by LS1010-2 upon detection of the failure
  
  1d03h: % OAM Pkt Sent
  1d03h: % Intf: 0/0/0 VPI: 1 VCI: 116 OAM: F5-AIS
  1d03h: % OAM Pkt Rcv
  1d03h: % Intf: 0/0/0 VPI: 1 VCI: 116 OAM: F5-RDI 
  
  ! RDI sent by Bernard upstream compared to the failure
  
  1d03h: % OAM Pkt Sent
  1d03h: % Intf: 0/0/1 VPI: 1 VCI: 116 OAM: F5-RDI 
  
  ! Bernard's RDI forwarded upstream
  
  1d03h: % OAM Pkt Rcv
  1d03h: % Intf: 0/0/1 VPI: 1 VCI: 116 OAM: F5-AIS
  
  1d03h: % OAM Pkt Sent
  1d03h: % Intf: 0/0/0 VPI: 1 VCI: 116 OAM: F5-AIS

  Et ainsi de suite jusqu'à la panne est éliminé.

• Sur LS1010-2 :

  À la découverte de la panne (dans ce cas le Rx-signal disparaît sur l'atmosphère 1/1/2 international connectée au Guilder), des cellules AIS sont envoyées à en aval à LS1010-1 :

  Mar 31 13:17:09.847: % OAM Pkt Sent
  Mar 31 13:17:09.847: % Intf: 0/0/0 VPI: 1 VCI: 116 OAM: F5-AIS
  
  Mar 31 13:17:10.847: % OAM Pkt Sent
  Mar 31 13:17:10.847: % Intf: 0/0/0 VPI: 1 VCI: 116 OAM: F5-AIS

  Comme vous pouvez également voir dans le tout les met au point jusqu'ici, toutes les cellules F5 OAM sont envoyées sur VPI 1 VCI 116, qui est le VPI/VCI utilisé par les cellules de l'utilisateur.

Commandes debug et show

• mettez au point l'oam atmosphère (sur des Routeurs)

• show atm pvc vpi/vci avec 12.0 et 12.0T

• <vcd> de show atm vc avec 11.1CC

• affichez l'atmosphère X [/y/ [z]]] .w (nous international vous recommandons show atm pvc d'utilisation si possibles au lieu de l'atmosphère de l'exposition international x) avec 12.0

Informations connexes

• Utilisation d'OAM pour la gestion PVC
• Pages de support technologique atmosphère
• Guide de dépannage CRC pour les interfaces ATM
• Dépannage des défaillances PVC lors de l'utilisation des cellules OAM et de la gestion PVC
• Outils et ressources
• Support et documentation techniques - Cisco Systems