Sommario

Introduzione

Operazioni preliminari

Convenzioni

Prerequisiti

Componenti usati

Esempio di rete

Rilevamento errori

Celle di loopback OAM

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

Comandi debug e show

Informazioni correlate

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:

- 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):

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.

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

- Utilizzo di OAM per la gestione del PVC

- Pagine di supporto per la tecnologia ATM

- Guida alla risoluzione dei problemi CRC per interfacce ATM

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

- Strumenti e risorse

- Documentazione e supporto tecnico – Cisco Systems