Troubleshooting de Alarmes de Camada Física em Links SONET e SDH

Introduction

Este documento explica os alarmes SONET comuns e como solucioná-los.

A vigilância de alarme usa dois termos:

• Estado—Condição que é informada ou detectada. Um dispositivo SONET entra em um estado quando o dispositivo detecta a ocorrência de um evento. Um dispositivo SONET sai desse estado quando o dispositivo não detecta mais o evento. Este documento discute a perda de sinal (LOS) e os estados de perda de quadro (LOF).

• Indicação — Solicitado por uma alteração de estado. Isso indica a presença de uma condição. Este documento discute as indicações de sinal de indicação de alarme (AIS - Alarm Indication Signal), indicador de defeito remoto (RDI - Remote Defect Indicator) e de falha de recepção da extremidade oposta (FERF - far-end receive failure).

Os alarmes ou defeitos ativos mantêm uma interface no estado inativo/inativo. O processo usado para solucionar problemas de interfaces SONET down/down é semelhante ao das interfaces digitais, como T1 e T3.

Prerequisites

Requirements

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

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Alarmes nas camadas do SONET

O equipamento SONET detecta eventos e alarmes em cada uma das três camadas da SONET: seção, linha e caminho. Geralmente, um dispositivo SONET envia alarmes de upstream e downstream para notificar outros dispositivos da condição do problema.

Emita o comando pos report para configurar os alarmes que a interface POS (packet over SONET, pacote sobre SONET) pode ativar.

RTR12410-1(config)#interface pos 2/1
   RTR12410-1(config-if)#pos report ? 
  all     all Alarms/Signals 
  b1-tca  B1 BER threshold crossing alarm 
  b2-tca  B2 BER threshold crossing alarm 
  b3-tca  B3 BER threshold crossing alarm 
  lais    Line Alarm Indication Signal 
  lrdi    Line Remote Defect Indication 
  pais    Path Alarm Indication Signal 
  plop    Path Loss of Pointer 
  prdi    Path Remote Defect Indication 
  rdool   Receive Data Out Of Lock 
  sd-ber  LBIP BER in excess of SD threshold 
  sf-ber  LBIP BER in excess of SF threshold 
  slof    Section Loss of Frame 
  slos    Section Loss of Signal

O comando show controllers exibe o número de vezes que um alarme é declarado e se algum alarme está ativo em uma interface POS e ATM sobre SONET. Essa saída foi capturada em um Roteador Switch Gigabit (GSR). A seção Defeitos ativos indica o que a interface local vê. A seção Alarmes ativos indica o que o dispositivo upstream relata.

RTR12410-1#show controller pos 1/0
POS1/0 
SECTION 
  LOF = 1         LOS    = 1                       BIP(B1) = 31165 
LINE 
  AIS = 1         RDI    = 0     FEBE = 0          BIP(B2) = 0 
PATH 
  AIS = 1         RDI    = 1     FEBE = 0          BIP(B3) = 25614 
  LOP = 0         NEWPTR = 1     PSE  = 0          NSE     = 0 
Active Defects: SLOF SLOS B1-TCA LAIS PAIS PRDI B3-TCA 
Active Alarms:  SLOS B1-TCA B3-TCA 
Alarm reporting enabled for: SF SLOS SLOF B1-TCA B2-TCA PLOP B3-TCA

Este exemplo de saída também foi capturado de um GSR. A mensagem LINK-3-UPDOWN indica que a camada física está ativa e que agora todos os alarmes ativos estão livres. A mensagem LINEPROTO-5-UPDOWN indica que o protocolo de linha está ativo; o protocolo de linha nas interfaces POS é Frame Relay, High-Level Data Link Control (HDLC) ou Point-to-Point Protocol (PPP).

Aug  7 05:14:37 BST: %LINK-3-UPDOWN: Interface POS4/7, changed state 
     to up 
     Aug  7 05:14:38 BST: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
     POS4/7,changed state to up 
     Aug  7 05:14:49 BST: %SONET-4-ALARM:  POS4/7: LRDI cleared      
     Aug  7 05:14:52 BST: %SONET-4-ALARM:  POS4/7: LRDI 
     Aug  7 05:15:02 BST: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
     POS4/7, changed state to down 
     
! --- Router receives the Line Remote Defect Indicator (LRDI) ! --- and brings down the line protocol.
 
      
     Aug  7 05:15:13 BST: %SONET-4-ALARM:  POS4/7: LRDI cleared      
     Aug  7 05:16:42 BST: %SONET-4-ALARM:  POS4/7: LRDI 
     Aug  7 05:16:45 BST: %SONET-4-ALARM:  POS4/7: SLOS 
     Aug  7 05:16:47 BST: %LINK-3-UPDOWN: Interface POS4/7, changed state 
     to down 
     Aug  7 05:16:56 BST: %SONET-4-ALARM:  POS4/7: LRDI cleared      
     Aug  7 05:16:56 BST: %SONET-4-ALARM:  POS4/7: PRDI 
     Aug  7 05:17:49 BST: %SONET-4-ALARM:  POS4/7: LRDI

Observação: para capturar timestamps granulares em mensagens de log, configure o comando service timestamps log datetime msec.

Um roteador com ATM em interfaces SONET também relata alarmes ativos com essas mensagens de registro:

Feb 18 16:34:22.309: %SONET-4-ALARM: ATM5/0: ~SLOF SLOS LAIS ~LRDI PAIS PRDI ~PLOP

O caractere "~" indica que o alarme específico está inativo, e a ausência do caractere ~ indica que o alarme está ativo. Nesta saída de exemplo, ~SLOF indica que não há perda de seção de erros de quadro. No entanto, a interface experimenta vários outros alarmes ativos que incluem perda de seção de sinal (SLOS) e sinal de indicação de alarme de linha (LAIS).

Indicadores de alarme

Geralmente, uma condição de falha detectada por um dispositivo SONET resulta em uma ou mais condições de erro enviadas upstream e downstream na rede. Um AIS é enviado para alertar os dispositivos de downstream sobre um problema e para evitar que falhas de downstream ou alarmes consequentes sejam aumentados. Um alarme RDI é enviado para cima como um mecanismo de controle e feedback para a rede. Anteriormente, o RDI era conhecido como FERF.

O RDI é diferente do REI (Remote Error Indicator, indicador de erro remoto). O REI comunica valores de monitoramento de desempenho, como taxas de erro de bits.

Troubleshooting

Use esta tabela para isolar e solucionar problemas de alarmes SONET. Observe a camada SONET na qual erros e alarmes são detectados, quando você soluciona problemas. Por exemplo, realize um teste ampliado do link ponto a ponto se as interfaces POS reportarem apenas erros de camada de caminho. Observe também o que os dispositivos upstream e remotos veem.

router(config-if)# [no] pos framing-sdh

Solucionar problemas com comandos de loopback

O teste de loopback permite que você teste a conexão entre a interface OC-3 e um dispositivo remoto para solucionar problemas, detectar e isolar defeitos de equipamentos. O comando loopback coloca uma interface no modo internal loopback (também chamado de local loopback) ou line loopback, o que permite testar os pacotes gerados pelo comando ping para loop através de um dispositivo ou cabo remoto. Se os pacotes concluírem o loop, é sinal de que a conexão está correta. Caso contrário, você pode isolar uma falha no dispositivo remoto ou no cabo no caminho do teste de loopback.

Com circuito de retorno interno, observe:

• Ao configurar um loopback, certifique-se de configurar a interface para o clock interno com o comando clock source internal. O framer espera quadros válidos de entrada com os quais sincronizar e usa esses quadros para cronometrar sua transmissão, quando configurado para a linha de origem do relógio. Sem quadros de recepção, você não tem tempo para enviar quadros.

• Se você fizer um loop de hardware — em outras palavras, você simplesmente coloca a fibra de volta na interface — certifique-se de usar um atenuador se você usa uma interface de modo único. Caso contrário, você pode ampliar a interface com muita energia ou até mesmo danificar a óptica da placa se for uma placa de Longo Alcance ou se a transmissão enviar acima dos níveis nominais.

Configurar uma interface para loopback interno

A configuração padrão de circuito de retorno é sem circuito de retorno. Com loopback interno (ou local), os pacotes do roteador executam loopback no quadro. Os dados de saída são devolvidos em circuito ao receptor sem terem sido realmente transmitidos. O loopback interno é útil quando você deseja verificar se a interface POS funciona. Para configurar uma interface para loopback interno, execute o comando loop internal:

Router(config)#interface pos 3/0
Router(config-if)#loop internal

Configurar uma interface para loopback de linha

A configuração padrão de circuito de retorno é sem circuito de retorno. Com o loopback de linha, a fibra de recepção (Rx) é conectada logicamente ao cabo de fibra óptica de transmissão (Tx), de modo que os pacotes do roteador remoto sejam retornados a ele. Os dados recebidos percorrem o circuito e são retransmitidos sem ter sidos recebidos efetivamente. Para configurar uma interface para loopback de linha, execute o comando loop line:

Router(config)#interface pos 3/0
Router(config-if)#loop line

Observação: o comando loopback line faz loops no sinal antes do framer SONET.

Configurar disparadores de retardo SONET

Um disparador é um alarme que, quando transmitido, faz com que o protocolo de linha se torne inativo. Estas seções abordam disparadores de linha e de caminho, que podem ser configurados através do comando pos delay triggers.

RTR12410-1(config)#interface pos 1/0 
   RTR12410-1(config-if)#pos delay triggers ? 
  line  Specify delay for SONET LINE level triggers (S-LOS, S-LOF, L-AIS) 
  path  Enable SONET PATH level triggers (P-AIS, P-RDI), with optional delay 
RTR12410-1(config-if)#pos delay triggers line ? 
  <0-511>  Holdoff time, in msec 
  <cr>

Disparadores de linha e seção

Você usa o comando pos delay triggers line para interfaces POS do roteador Internet conectadas a sistemas DWDM (Dense Wavelength Division Multiplexing) protegidos internamente (documentados em CSCdm36033 e CSCdp65436 nos roteadores da série Cisco 12000 e CSC7 2941 nos roteadores das séries Cisco 7200 e 7500). Este comando é inválido para interfaces configuradas como APS funcionando ou protegidas. Normalmente, mesmo alguns microssegundos de alarmes de linha ou nível de seção (SLOS, SLOF ou LAIS) desativam o link até que o alarme fique claro por dez segundos. Se você configurar holdoff, esse disparador de link down será atrasado para 100 ms. Se o alarme permanecer ativo por mais de 100 ms, o link será desativado como está agora. Se o alarme desaparecer antes de 100 ms, o link não será desativado.

Por padrão, esses alarmes de seção e linha são disparos para que o protocolo de linha fique inativo:

• Perda de sinal da seção

• Perda de quadro da seção

• Sinal indicativo de alarme de linha

O protocolo de linha da interface fica inativo sem um atraso quando um ou mais desses alarmes são afirmados. Você pode emitir o comando pos delay triggers line para atrasar o encerramento do protocolo de linha da interface. Você pode definir o atraso de 0 a 511 ms. O atraso padrão é definido como 100 ms se você não especificar um intervalo de tempo.

Disparadores do nível de caminho

Esses alarmes de caminho não são disparadores por padrão. É possível configurar esses alarmes de caminho como disparos e também especificar um atraso:

• Sinal de indicação de alarme do caminho

• Indicação de defeito remoto de caminho

• Perda de caminho do ponteiro

Você pode emitir o comando pos delay triggers path para configurar vários alarmes de caminho como disparadores e para especificar um atraso de ativação entre 0 e 511 ms. O valor de atraso padrão é 100 ms.

A configuração de caminho dos disparadores após o retardo também pode desativar o protocolo de linha quando as mais altas das taxas de erro de B2 e B3 são comparadas com o limiar de falha de sinal (SF). Se o limiar de SF for cruzado, o protocolo de linha da interface é desativado.

O comando pos delay triggers path foi introduzido na versão 12.0(16)S do software Cisco IOS®.

MIB de SONET

As interfaces Cisco SONET também suportam a MIB SONET, definida na RFC (Request for Comments, solicitação de comentários) 1595 . O RFC usa a mesma terminologia para descrever condições de erro em um circuito SONET que os padrões ANSI para SONET e em um circuito SDH (Synchronous Digital Hierarchy) pela especificação da International Telecommunications Union (ITU-T) G.783.

Para obter suporte de MIB SONET em interfaces Cisco POS e ATM sobre SONET, consulte estes recursos:

• MIBs da Cisco —Lista as MIBs suportadas por plataforma, bem como as strings de ID de objeto e os arquivos .my para a MIB SONET.

• Família Cisco 7000 e 12000 Series — Release Notes para Release 12.0 S - Descreve melhorias no suporte da Cisco para o SONET MIB.

Informações Relacionadas

• Páginas de suporte de hardware óptico
• Páginas de suporte de tecnologia ótica
• Suporte Técnico - Cisco Systems

Histórico de revisões