Asynchronous Transfer Mode (ATM) : Permanent Virtual Circuits (PVC) e Switched Virtual Circuits (SVC)

Troubleshooting de Falhas de PVC na Utilização de Células de OAM e Gerenciamento de PVC

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Caso ocorra um problema de comunicação em um PVC (nenhum tráfego em uma direção ou em outra), o Circuito Virtual Permanente (PVC) permanecerá UP nos dispositivos finais. Portanto, as entradas de roteamento que apontavam para o PVC permanecem na tabela de roteamento durante um determinado período, resultando na perda de pacotes. A solução desse problema é usar o OAM (Operação e Manutenção) para detectar essas falhas e permitir ao PVC desconectar se ele for interrompido ao longo de seu caminho.

É possível exibir configuração de exemplo sobre a utilização de OAM para gerenciamento de PVC clicando aqui.

Antes de Começar

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Pré-requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

O OAM e o gerenciamento de PVC são apoiados desde a versão 11.1(22)CC do ½ do ¿  de Cisco IOSï e na versão do Cisco IOS 12.0 e mais atrasado.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Diagrama de Rede

Este documento baseia-se na seguinte configuração:

/image/gif/paws/21424/oam-netw.jpg

  • 1/116 é o VPI/VCI alocado para o circuito virtual (VC) no caminho completo.

  • Switches ATM está executando o Cisco IOS 12.0. Switches ATM foi configurado para enviar o Alarm Indication Signal/Remote Defect Indicator (AIS/RDI) em cima da falha do link, como explicado neste documento.

  • Você pode produzir falhas desligando a (sub) interface em Guilder e observando o que ocorre em Bernard. Nós permitimos o service timestamps debug datetime msec nas configurações para o todo o debugamos neste documento. Isto permite que nós ver a época do cada eventos no milissegundo.

Detectando falhas

Nós consideraremos somente pilhas F5 OAM (nível VC) para este documento desde que estes são únicos usados por dispositivos finais de Cisco (Roteadores) para detectar falhas. A fim detectar uma falha ao longo do trajeto PVC em um dispositivo final, o OAM usa estas pilhas específicas:

  • Células de loopback

  • Pilhas do Continuity Check (CC)

  • Pilhas do sinal de indicação do alarme (AIS)

  • Pilhas do Remote Detection Indication (RDI)

Há três circunstâncias para declarar ACIMA um PVC:

  • O roteador recebe um número configurado de respostas fim-a-fim sucessivas da pilha do loopback de OAM F5.

  • O roteador não recebe pilhas F5-AIS por 3 segundos.

  • O roteador não recebe pilhas F5-RDI por 3 segundos.

A próxima seção descreve estas pilhas e saídas que mostram seus efeitos.

Células de circuito de retorno OAM

Em intervalos regulares, os dispositivos finais (tais como o Roteadores) configurados para o OAM enviam as células de loopback que devem ser dadas laços na rede. Este ponto dando laços pode ser a máquina no fim do PVC (células de loopback de ponta a ponta) ou em um equipamento no trajeto (pilhas do loopback de segmento).

Os identificadores na célula de loopback indicam que dispositivos devem dar laços na pilha. Um dispositivo Cisco que termine um VC ao receber tal pilha em um PVC dará laços n mesmo se não é configurado para o OAM. Também, cada um destas pilhas conterá um indicador do “sentido” (para identificar se é um comando ou uma célula de resposta) e um número de sequência (chamado caracteres de correlação ou CTag no debuga). A célula de loopback do “comando” e a célula de loopback da “resposta” terão o mesmo número de sequência.

O seguinte diagrama ilustra pilhas do laço de retorno (LB):

/image/gif/paws/21424/oam-lb.jpg

Exemplo de debug

As seguintes mostras debugam (debug atm oam) que ilustra as células de loopback em 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

Comentários no exemplo de debug

  • A primeira linha indica que o cronômetro utilizado para identificar quando uma célula de loopback é emitida em uma (sub)interface expirou.

  • A célula de loopback do comando A é mandada então na interface correspondente (a segunda linha de debuga). O valor ctag indicado nesta linha é o valor hexadecimal da primeira linha CTag mais um.

  • Em seguida, uma célula de circuito fechado fendida é recebida com um LoopInd igual a zero.

Nota: LoopInd=1 indica que uma célula de comando e um LoopInd=0 indicam uma pilha da resposta (dada laços). LoopInd=1 não indica no debuga, mas apareceria em um farejador de rastreamento.

Exemplo de debug (se as células de loopback são perdidas)

Considere um dispositivo (usando PVCs) configurado para enviar células de OAM e usando gerenciamento de PVC. Se esse equipamento perde um certo número de células de loopback, colocará o PVC em um estado desativado. Veja que o seguinte debuga:

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

Você pode configurar a quantidade de pilhas perdidas necessárias pôr para baixo o PVC. O seguinte comando show atm pvc vpi/vci explica o precedente debuga.

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

Como você pode ver, os laços de retorno F5 foram enviados, mas não respondidos (18 F5 OutEndloop mas somente 9 F5 InEndloop; consequentemente, as células de loopback 9 dadas laços F5 foram perdidas.). Isso causou a desativação do PVC (já que o gerenciamento do PVC está configurado). F5 OutEndloop representa o número de células de loopback enviadas e F5 InEndloop representa o número de células de loopback recebidas.

Como você pode igualmente ver, os contadores de célula de OAM F4 estam presente, mas nada está sendo gravado desde que somente as pilhas F5 são consideradas aqui. Na saída do comando show acima, outras informações interessantes podem ser coletadas com relação às células de loopback:

  • As células de OAM são enviadas os segundos cada 10 apesar de se o PVC é para cima ou para baixo.

  • Se o PVC está acima mas a outra extremidade não está respondendo, o roteador tenta enviar em segundo a economia de célula OAM até que receba uma resposta ou até que as células de OAM 5 não estejam respondidas. Então o PVC vai para baixo (veja debuga acima).

  • Na outra extremidade, se o PVC está para baixo e recebe de repente uma célula válida em loop, tentará enviar novamente células de LB cada segundo até que 3 células válidas de loopbacks de circuito estejam recebidas em seguido. Em seguida, o PVC ficará ativo novamente. Consulte as depurações a seguir.

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

Como você pode ver, a secundário-relação (daqui o PVC) foi trazida acima outra vez após a recepção de três células de loopback da resposta válida em seguido.

Nota: O usuário pode configurar todos os parâmetros descritos acima, assim como usa o comando show atm pvc vpi/vci verificar os parâmetros.

Alarm Indication Signal/Remote Defect Indicator (AIS/RDI)

Após detecção de uma falha, um dispositivo configurado para o OAM envia o downstream de frames AIS e envia quadros RDI rio acima.

O exemplo seguinte ilustra o AIS e as células de RDI. Supõe que o sinal RX desaparece em um interruptor. A falha, neste caso, é chamada de LOS (Perda de sinal). O interruptor que a detectou envia um downstream de AIS comparado à falha e um RDI comparada rio acima à falha.

/image/gif/paws/21424/aisrdi.jpg

Ao receber tais pilhas, um dispositivo final configurado para o gerenciamento de PVC derruba o PVC afetado. Essas células AIS e RDI são enviadas usando os mesmos VPI/VCI como células de usuário no PVC. Além disso, o dispositivo envia essas células a cada segundo até que a falha desapareça.

Exemplo de debug

Você pode detectar uma falha em diversas maneiras:

  • Um nível mais baixo OAM (F1 AIS, a perda de sinal, e assim por diante) relatam-na.

  • A recepção de um AIS ou de um RDI provoca-o.

  • O dispositivo já não recebe pilhas CC.

Uma pilha do Continuity Check (CC) é uma pilha que os dispositivos configurados para o OAM regularmente enviem e se usem para verificar a integridade do “link”. Os roteadores Cisco não enviam estas pilhas assim que não são discutidos aqui. Para obter mais informações sobre células CC de OAM, consulte ITU-T I.610.

Os seguintes debugam mostram o que acontece em um roteador configurado para o gerenciamento de PVC após recepção de uma pilha 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

Neste momento, o PVC em Bernard vai para baixo (a interface principal no florim é fechada):

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

Você pode verificar o estado novo PVC com o comando seguinte:

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

Como você pode ver, o PVC foi para baixo porque recebeu um sinal F5 AIS ou RDI (neste caso particular um AIS). Você pode igualmente ver que o roteador gerou as células de RDI F5 após recepção das células AIS F5.

O exemplo seguinte ilustra a atividade nos dois Switches no trajeto:

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

    Nesse ponto, o PVC fica inativo no 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

    E assim por diante, até que a falha seja eliminada.

  • No LS1010-2:

    Em caso de detecção da falha (nesse caso, o sinal de Rx desaparece no int atm 1/1/2 conectado ao Guilder), as células AIS são enviadas downstream para o 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

    Como você pode igualmente ver no todo o debuga até agora, todas as células de OAM F5 são enviadas no VPI1 VCI 116, que é o VPI/VCI usado pelas pilhas do usuário.

comandos debug e show

  • debug atm oam (no Roteadores)

  • mostre o vpi/vci pvc atm com 12.0 e 12.0T

  • mostre o <vcd> atm vc com 11.1CC

  • mostre o [/y/[z]]] .w int atm x (nós o recomendamos pvc atm da mostra do uso quando possíveis em vez da mostra int atm x) com 12.0


Informações Relacionadas


Document ID: 21424