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.
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
Não existem requisitos específicos para este documento.
Gerenciamento de OAM ou PVC é suportado desde o Cisco IOS® versão 11.1(22)CC e no Cisco IOS versão 12.0 e posterior.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.
Este documento baseia-se na seguinte configuração:
1/116 é o VPI/VCI alocado para o circuito virtual (VC) no caminho completo.
Os switches ATM estão executando o Cisco IOS 12.0. Os switches ATM foram configurados para enviar o Alarm Indication Signal/Remote Defect Indicator (AIS/RDI) em caso de falha de link, conforme explicado neste documento.
Você pode produzir falhas desligando a (sub) interface em Guilder e observando o que ocorre em Bernard. Habilitamos service timestamps debug datetime msec nas configurações para todas as depurações neste documento. Isso nos permite ver o tempo de cada evento em ms.
Consideraremos apenas as células OAM F5 (nível VC) para este documento, pois essas são as únicas usadas pelos dispositivos finais da Cisco (roteadores) para detectar falhas. Para detectar uma falha ao longo do caminho do PVC em um dispositivo final, o OAM usa estas células específicas:
Células de loopback
Células de verificação de continuidade (CC)
Células de Sinal de Indicação de Alarme (AIS - Alarm Indication Signal).
Células de indicação de detecção remota (RDI)
Há três condições para declarar um PVC UP:
O roteador recebe um número configurado de sucessivas respostas de célula de loopback F5 OAM fim-a-fim.
O roteador não recebe células F5-AIS por 3 segundos.
O roteador não recebe células F5-RDI por 3 segundos.
A próxima seção descreve essas células e resultados mostrando seus efeitos.
Em intervalos regulares, os dispositivos finais (como roteadores) configurados para OAM enviam células de loopback que devem estar em loop na rede. Esse ponto de loop pode ser a máquina na extremidade do PVC (células de loopback de ponta a ponta) ou um equipamento no caminho (células de loopback de segmento).
Os identificadores na célula de loopback indicam que dispositivo(s) deve(m) fazer loop na célula. Um dispositivo da Cisco que encerra um VC ao receber tal célula em um PVC irá colocá-la em loop, mesmo que não esteja configurado para OAM. Além disso, cada uma dessas células conterá um indicador de "direção" (para identificar se é uma célula de comando ou resposta) e um número de sequência (chamado tag de correlação ou CTag nas depurações). A célula de loopback de "comando" e a célula de loopback de "resposta" terão o mesmo número de sequência.
O diagrama a seguir ilustra as células de loopback (LB):
A seguir estão as depurações (debug atm oam) que ilustram 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
A primeira linha indica que o cronômetro utilizado para identificar quando uma célula de loopback é emitida em uma (sub)interface expirou.
Em seguida, uma célula de loopback de comando é enviada para fora na interface correspondente (segunda linha das depurações). O valor CTag exibido 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.
Observação: LoopInd=1 indica uma célula de comando e LoopInd=0 indica uma célula de resposta (em loop). LoopInd=1 não é exibido nas depurações, mas apareceria em um rastreamento de farejador.
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 as seguintes depurações:
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 células perdidas necessárias para colocar o PVC no lugar. O seguinte comando show atm pvc vpi/vci explica as depurações anteriores.
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, loopbacks F5 foram enviados, mas não respondidos (18 F5 OutEndloop, mas somente 9 F5 InEndloop; portanto, 9 células de loopback em loop 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ê também pode ver, os contadores de célula OAM F4 estão presentes, mas nada está sendo gravado, pois somente as células 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 OAM são enviadas a cada 10 segundos, independentemente de o PVC estar ativo ou inativo.
Se o PVC estiver ativo, mas a outra extremidade não estiver respondendo, o roteador tentará enviar célula OAM por segundo até receber uma resposta ou até que 5 células OAM não tenham sido respondidas. Em seguida, o PVC cai (consulte depurações acima).
Na outra extremidade, se o PVC estiver inoperante e receber de repente uma célula em loop válida, ele tentará reenviar células LB a cada segundo até que 3 células em loop válidas em uma linha sejam recebidas. 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 subinterface (daí o PVC) foi ativada novamente após a recepção de três células de loopback de resposta válidas em uma linha.
Observação: o usuário pode configurar todos os parâmetros descritos acima, bem como usar o comando show atm pvc vpi/vci para verificar os parâmetros.
Após a detecção de uma falha, um dispositivo configurado para OAM envia quadros AIS downstream e envia quadros RDI upstream.
O exemplo a seguir ilustra as células AIS e RDI. Suponha que o sinal Rx desaparece em um switch. A falha, neste caso, é chamada de LOS (Perda de sinal). O Switch que fizer a detecção faz o envio de um downstream de AIS comparado com a falha e um upstream de RDI comparado com a falha.
Ao receber essas células, um dispositivo final configurado para gerenciamento de PVC derruba os PVCs afetados. 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.
Você pode detectar uma falha de várias maneiras:
Um nível OAM mais baixo (F1 AIS, perda de sinal e assim por diante) o relata.
A recepção de um AIS ou RDI a aciona.
O dispositivo não recebe mais células CC.
Uma célula de verificação de continuidade (CC) é uma célula que os dispositivos configurados para OAM enviam e usam regularmente para verificar a integridade do "link". Os roteadores Cisco não enviam essas células, portanto, elas não são discutidas aqui. Para obter mais informações sobre células CC de OAM, consulte ITU-T I.610.
A depuração a seguir mostra o que acontece em um roteador configurado para gerenciamento de PVC na recepção de uma célula 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
Nesse ponto, o PVC de Bernard cai (a interface principal de Guilder é desligada):
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 novo estado do PVC com o seguinte comando:
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 caiu porque recebeu um sinal F5 AIS ou RDI (neste caso específico um AIS). Você também pode ver que o roteador gerou células RDI F5 ao receber as células AIS F5.
O exemplo a seguir ilustra a atividade dos dois switches no caminho:
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ê também pode ver em todas as depurações até agora, todas as células OAM F5 são enviadas em VPI 1 VCI 116, que é o VPI/VCI usado pelas células do usuário.
debug atm oam (em roteadores)
show atm pvc vpi/vci com 12.0 e 12.0T
show atm vc <vcd> com 11.1CC
show int atm x[/y/[z]].w (recomendamos que você use show atm pvc quando possível, em vez de show int atm x) com 12.0
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
15-Nov-2007 |
Versão inicial |