Risoluzione dei problemi relativi agli errori PVC quando si utilizzano le celle OAM e la gestione PVC

Opzioni per il download

  • PDF     (257.0 KB)
    Visualizza con Adobe Reader su diversi dispositivi
  • ePub     (134.9 KB)
    Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (130.7 KB)
    Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi
Aggiornato:15 novembre 2007
ID documento:21424

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

Introduzione

Se si verifica un problema di comunicazione su un PVC (nessun traffico in un modo o nell'altro), il circuito virtuale permanente (PVC) rimane ATTIVO sui dispositivi terminali. Pertanto, le voci di routing che puntavano al PVC rimangono nella tabella di routing per un determinato periodo di tempo e, di conseguenza, i pacchetti andranno persi. La soluzione a questo problema consiste nell'utilizzare l'operazione e la manutenzione (OAM) per rilevare tali errori e consentire la disconnessione del PVC se viene interrotto lungo il percorso.

Per visualizzare una configurazione di esempio sull'utilizzo di OAM per la gestione del PVC, fare clic qui.

Operazioni preliminari

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Prerequisiti

Non sono previsti prerequisiti specifici per questo documento.

Componenti usati

La gestione di OAM e PVC è supportata a partire dalla versione 11.1(22)CC di Cisco IOS® e dalla versione 12.0 di Cisco IOS e successive.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Esempio di rete

Questo documento si basa sulla seguente impostazione:

oam-netw.jpg

  • 1/116 è il VPI/VCI assegnato al circuito virtuale (VC) sul percorso completo.

  • Sugli switch ATM è in esecuzione Cisco IOS 12.0. Gli switch ATM sono stati configurati per inviare il segnale di avviso/indicatore di guasto remoto (AIS/RDI) in caso di guasto del collegamento, come spiegato in questo documento.

  • Potete produrre dei fallimenti chiudendo l'interfaccia (secondaria) su Guilder e osservando cosa succede su Bernard. Nelle configurazioni per tutti i debug di questo documento sono stati abilitati i timestamp del servizio come datetime di debug. In questo modo è possibile visualizzare l'ora di ogni evento in millisecondi.

Rilevamento errori

Verranno prese in considerazione solo le celle F5 OAM (livello VC) per questo documento, in quanto sono le uniche utilizzate dai dispositivi terminali (router) Cisco per rilevare gli errori. Per rilevare un errore nel percorso PVC di un dispositivo terminale, OAM utilizza le seguenti celle specifiche:

  • Celle loopback

  • Celle Continuity Check (CC)

  • Celle del segnale di indicazione di allarme (AIS)

  • Celle RDI (Remote Detection Indication)

Ci sono tre condizioni per dichiarare un PVC UP:

  • Il router riceve un numero configurato di risposte successive di celle di loopback OAM F5 end-to-end.

  • Il router non riceve celle F5-AIS per 3 secondi.

  • Il router non riceve celle F5-RDI per 3 secondi.

Nella sezione successiva vengono descritte le celle e gli output con i relativi effetti.

Celle di loopback OAM

A intervalli regolari, i dispositivi finali (ad esempio i router) configurati per OAM inviano le celle di loopback che devono essere sottoposte a loop nella rete. Questo punto di loop può essere la macchina alla fine del PVC (cellule di loopback end-to-end) o un'apparecchiatura sul percorso (celle di loopback del segmento).

Gli identificatori nella cella di loopback indicano quali periferiche devono eseguire il loop nella cella. Un dispositivo Cisco che termina un VC quando riceve una cella di questo tipo su un PVC la ricetrasmette anche se non è configurato per OAM. Inoltre, ognuna di queste celle conterrà un indicatore di "direzione" (per identificare se si tratta di una cella di comando o di risposta) e un numero di sequenza (chiamato tag Correlation o CTag nei debug). La cella di loopback "command" e la cella di loopback "response" avranno lo stesso numero di sequenza.

Il diagramma seguente illustra le celle di loopback (LB):

oam-lb.jpg

Output di esempio del comando debug

Di seguito sono illustrati i debug (debug atm oam) che illustrano le celle di loopback su 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

Commenti sull'output di esempio del comando debug

  • La prima riga indica che il timer utilizzato per identificare quando una cella di loopback deve essere emessa su un'interfaccia (secondaria) è scaduta.

  • Una cella di loopback dei comandi viene quindi inviata all'interfaccia corrispondente (seconda riga dei debug). Il valore CTag visualizzato su questa riga è il valore esadecimale della prima riga CTag più uno.

  • Viene quindi ricevuta una cella di loopback con un oggetto LoopInd uguale a zero.

Nota: LoopInd=1 indica una cella di comando e LoopInd=0 indica una cella di risposta (con ciclo). LoopInd=1 non viene visualizzato nei debug, ma verrebbe visualizzato in una traccia di sniffer.

Output di esempio del comando debug (se le celle di loopback vengono perse)

Si consideri un dispositivo (che utilizza PVC) configurato per l'invio di celle OAM e la gestione di PVC. Se questa apparecchiatura perde un certo numero di celle di loopback, mette il PVC nello stato Down. Vedere i seguenti debug:

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

È possibile configurare la quantità di celle perse necessarie per l'abbassamento del PVC. Il seguente comando show atm pvc vpi/vci spiega i debug precedenti.

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

Come si può vedere, F5 loopback sono stati inviati, ma non hanno risposto (18 F5 OutEndloop ma solo 9 F5 InEndloop; pertanto, sono state perse 9 celle loopback F5 con loop.) Ciò ha causato il guasto del PVC (poiché la gestione del PVC è configurata). F5 OutEndloop rappresenta il numero di celle di loopback inviate e F5 InEndloop rappresenta il numero di celle di loopback F5 ricevute.

Come si può anche vedere, sono presenti contatori di celle F4 OAM, ma non viene registrato nulla poiché vengono considerate solo le celle F5. Dall'output del comando show riportato sopra, è possibile raccogliere altre informazioni interessanti sulle celle di loopback:

  • Le celle OAM vengono inviate ogni 10 secondi indipendentemente dal fatto che il PVC sia attivo o inattivo.

  • Se il PVC è attivo ma l'altra estremità non risponde, il router tenta di inviare le celle OAM ogni secondo finché non riceve una risposta o finché non vengono risposte 5 celle OAM. Il PVC si abbassa (vedere i debug sopra).

  • D'altra parte, se il PVC è inattivo e riceve improvvisamente una cella con loop valido, proverà a inviare di nuovo le celle con loop ogni secondo finché non verranno ricevute 3 celle con loop back validi in una riga. Poi il PVC salirà di nuovo. Vedere i debug di seguito.

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

Come si può vedere, la sottointerfaccia (da cui il PVC) è stata richiamata dopo la ricezione di tre valide celle di loopback di risposta in una fila.

Nota: l'utente può configurare tutti i parametri descritti in precedenza, nonché utilizzare il comando show atm pvc vpi/vci per controllare i parametri.

Segnale di allarme/indicatore di guasto remoto (AIS/RDI)

Quando viene rilevato un errore, un dispositivo configurato per OAM invia i frame AIS a valle e invia i frame RDI a monte.

Nell'esempio seguente vengono illustrate le celle AIS e RDI. Si supponga che il segnale Rx scompaia da uno switch. Il guasto in questo caso si chiama perdita di segnale (LOS). Lo switch che ha rilevato l'errore invia un'interfaccia AIS a valle rispetto all'errore e un'interfaccia RDI a monte rispetto all'errore.

aisrdi.jpg

Quando si ricevono tali celle, un dispositivo terminale configurato per la gestione del PVC riduce i PVC interessati. Queste celle AIS e RDI vengono inviate utilizzando lo stesso VPI/VCI delle celle utente sul PVC. Inoltre, il dispositivo invia queste celle ogni secondo fino alla scomparsa del guasto.

Output di esempio del comando debug

È possibile rilevare un errore in diversi modi:

  • Un livello OAM inferiore (F1 AIS, perdita di segnale e così via) lo segnala.

  • La ricezione di un AIS o RDI lo attiva.

  • Il dispositivo non riceve più celle CC.

Una cella CC (Continuity Check) è una cella che i dispositivi configurati per OAM inviano e utilizzano regolarmente per verificare l'integrità del collegamento. I router Cisco non inviano queste celle, quindi non vengono discusse qui. Per ulteriori informazioni sulle celle OAM CC, consultare ITU-T I.610.

Il debug seguente mostra ciò che accade su un router configurato per la gestione del PVC alla ricezione di una cella 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

A questo punto, il PVC di Bernard si spegne (l'interfaccia principale di Guilder è chiusa): 

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

È possibile controllare il nuovo stato del PVC con il comando seguente:

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

Come si può vedere, il PVC è sceso perché ha ricevuto un segnale AIS o RDI F5 (in questo caso particolare un AIS). Potete anche vedere che il router ha generato celle F5 RDI alla ricezione delle celle F5 AIS.

L'esempio seguente mostra l'attività sui due switch del percorso:

  • Su 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

    A questo punto, il PVC si abbassa al Fiorino: 

    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

    E così via finché il fallimento non viene eliminato.

  • Su LS1010-2:

    Una volta rilevato il guasto (in questo caso il segnale Rx scompare su ATM 1/1/2 collegato al Guilder), le celle AIS vengono inviate a valle a 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

    Come si può anche vedere in tutti i debug finora, tutte le celle F5 OAM vengono inviate sul VPI 1 VCI 116, che è il VPI/VCI utilizzato dalle celle dell'utente.

Comandi debug e show

  • debug atm oam (su router)

  • mostra vpi/vci pvc atm con 12.0 e 12.0T

  • show atm vc <vcd> con 11.1CC

  • show int atm x[/y/[z]]].w (si consiglia di utilizzare show atm pvc quando possibile invece di show int atm x) con 12.0

Informazioni correlate

Cronologia delle revisioni

Revisione Data di pubblicazione Commenti
1.0
15-Nov-2007
Versione iniziale

Questo documento ti è stato utile?

FeedbackFeedback

Contattaci

Questo documento si applica a questi prodotti