Resolución de problemas de alarmas de capa física en links SONET y SDH

Introducción

Este documento explica las alarmas SONET comunes y cómo solucionar los problemas relacionados con ellas.

La vigilancia de alarmas utiliza dos términos:

• Estado: condición que se informa o se detecta. Un dispositivo SONET ingresa en un estado cuando el dispositivo detecta la aparición de un evento. Un dispositivo SONET sale de ese estado cuando el dispositivo ya no detecta el evento. Este documento analiza los estados de pérdida de señal (LOS) y de trama (LOF).

• Indicación: se le solicita un cambio de estado. Esto indica la presencia de una condición. Este documento trata las indicaciones de señal de indicación de alarma (AIS), indicador de defecto remoto (RDI) y FERF (FERF).

Las alarmas activas o los defectos mantienen una interfaz en el estado inactivo. El proceso utilizado para resolver problemas de interfaces SONET inactivas/inactivas es similar al de las interfaces digitales, como T1 y T3.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Alarmas en capas de SONET

El equipo SONET detecta eventos y alarmas en cada una de las tres capas de SONET: sección, línea y ruta. Por lo general, un dispositivo SONET envía alarmas tanto en sentido ascendente como descendente para notificar a otros dispositivos la condición del problema.

Ejecute el comando pos report para configurar las alarmas que la interfaz de paquete sobre SONET (POS) puede activar.

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

El comando show controllers muestra la cantidad de veces que se declara una alarma y si hay alarmas activas en un POS y ATM sobre la interfaz SONET. Esta salida se capturó en un router de switch Gigabit (GSR). La sección Defectos activos indica lo que ve la interfaz local. La sección Alarmas activas indica lo que informa el dispositivo ascendente.

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 ejemplo de resultado también se capturó de un GSR. El mensaje LINK-3-UPDOWN indica que la capa física se encuentra activada y que todas las alarmas activas han sido borradas. El mensaje LINEPROTO-5-UPDOWN indica que el protocolo de línea está activo; el protocolo de línea en las interfaces POS es Frame Relay, High-Level Data Link Control (HDLC) o 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

Nota: Para capturar sellos de hora granulares en los mensajes de registro, configure el comando service timestamps log datetime msec.

Un router con ATM sobre interfaces SONET también informa sobre alarmas activas con estos mensajes de registro:

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

El carácter "~" indica que la alarma específica no está activa y la ausencia de este carácter, que la alarma está activa. En este ejemplo de resultado, ~SLOF indica que no hay pérdidas de sección de errores de trama. Sin embargo, la interfaz experimenta otras alarmas activas que incluyen la pérdida de señal de sección (SLOS) y la señal de indicación de alarma de línea (LAIS).

Indicadores de alarma

Normalmente, una condición de falla detectada por un dispositivo SONET da como resultado una o más condiciones de error enviadas tanto en sentido ascendente como descendente en la red. Se envía un AIS para alertar a los dispositivos de flujo descendente de un problema y para evitar que se produzcan fallas o alarmas descendentes consecuentes. Una alarma RDI es enviada en sentido ascendente como control y mecanismo de retroalimentación para la red. Anteriormente, RDI se denominaba FERF.

El RDI es diferente del indicador de error remoto (REI). El REI comunica los valores de supervisión del rendimiento, como las tasas de error de bits.

Resolución de problemas

Utilice esta tabla para aislar y resolver problemas de alarmas SONET. Tenga en cuenta la capa SONET en la que se detectan errores y alarmas al resolver problemas. Por ejemplo, realice una prueba prolongada del link extremo a extremo si las interfaces POS informan sólo sobre errores de trayecto-capa. Observe también lo que ven los dispositivos ascendentes y remotos.

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

Solución de problemas con comandos loopback

La prueba de loopback le permite probar la conexión entre la interfaz OC-3 y un dispositivo remoto para resolver problemas, detectar y aislar fallas del equipo. El comando loopback coloca una interfaz en el loopback interno (también llamado loopback local) o en modo loop retorno de línea, el cual activa los paquetes de prueba que se generaron desde el comando ping hasta el loop a través de un dispositivo remoto o de un cable. Si los paquetes completan el loop, la conexión es buena. Si no, puede aislar una falla en el dispositivo remoto o el cable en la trayectoria de la prueba de loopback.

Con loopback interno, observe:

• Cuando configure un loopback, asegúrese de configurar la interfaz para la temporización interna con el comando clock source internal. El entramador espera tramas entrantes válidas con las que sincronizar y utiliza estas tramas para cronometrar su transmisión, cuando se configura para línea de origen de reloj. Sin tramas de recepción, no tiene tiempo para enviar tramas.

• Si hace un loop de hardware — en otras palabras, simplemente vuelve a colocar la fibra en la interfaz — asegúrese de utilizar un atenuador si utiliza una interfaz de modo único. Si no lo hace, podría hacer estallar la interfaz con demasiada energía o incluso dañar la óptica de la tarjeta si es una tarjeta de largo alcance o si la transmisión envía niveles más altos que sus niveles nominal.

Configuración de una Interfaz para Loopback Interno

La configuración predeterminada de loopback es para ningún loopback. Con el loopback interno (o local), los paquetes desde el router se devuelven en loop al framer. Los datos salientes pasan por un loopback al receptor sin ser transmitidos en realidad. El loopback interno es útil cuando desea verificar que la interfaz POS funciona. Para configurar una interfaz para loopback interno, ejecute el comando loop internal:

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

Configuración de una Interfaz para Loopback de Línea

La configuración predeterminada de loopback es para ningún loopback. Con el loopback de línea, la fibra de recepción (Rx) está conectada lógicamente al cable de fibra óptica de transmisión (Tx), de modo que los paquetes del router remoto vuelven a estar conectados en bucle. Los datos entrantes ingresan en un loop y son retransmitidos sin realmente ser recibidos. Para configurar una interfaz para el loopback de línea, ejecute el comando loop line:

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

Nota: El comando loopback line coloca la señal en bucle antes del entramador SONET.

Configurar los desencadenadores de retraso de SONET

Un disparador es una alarma que, cuando se verifica, hace que baje el protocolo de línea. Estas secciones analizan los activadores de línea y los activadores de trayecto que son configurados con el 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 línea y sección

Utilice el comando pos delay triggers line para las interfaces POS del router de Internet conectadas a sistemas de multiplexación por división de longitud de onda densa (DWDM) protegidos internamente (documentados en CSCdm36033 y CSCdp65436 en los routers de la serie Cisco 12000 y CSCdr7 941 en Cisco 7200 y 7500 Series Routers). Este comando no es válido para las interfaces configuradas como APS que funcionan o están protegidas. Normalmente, incluso unos pocos microsegundos de alarmas a nivel de línea o sección (SLOS, SLOF o LAIS) desactivan el link hasta que la alarma se ha despejado durante diez segundos. Si configura holdoff, este disparador de link descendente se retrasa 100 ms. Si la alarma permanece activa durante más de 100 ms, el link se desactiva tal como está ahora. Si se desactiva la alarma antes de 100 ms, el link no se interrumpirá.

De manera predeterminada, estas alarmas de sección y línea son disparadores para que el protocolo de línea falle.

• Sección pérdida de señal

• Sección pérdida de trama

• Señal de indicación de alarma de línea

El protocolo de línea de la interfaz se desactiva sin demora cuando se afirma una o más de estas alarmas. Puede ejecutar el comando pos delay triggers line para retrasar la caída del protocolo de línea de la interfaz. Puede establecer la demora de 0 a 511 ms. El retardo predeterminado se establece en 100 ms si no se especifica un intervalo de tiempo.

Disparadores de nivel de trayecto

Estas alarmas de trayectoria no son desencadenadores de forma predeterminada. Puede configurar estas alarmas de ruta como disparadores y también especificar un retraso:

• Señal de indicación de alarma de trayecto

• Indicación de defecto remoto de trayecto

• Pérdida de ruta del puntero

Puede ejecutar el comando pos delay triggers path para configurar diversas alarmas de trayectoria como disparadores y para especificar un retraso de activación entre 0 y 511 ms. El valor de retraso predeterminado es 100 ms.

La configuración de pos delay triggers path también puede desactivar el protocolo de línea cuando la tasa de error más alta de B2 y B3 es comparada con el umbral de Falla de señal (SF). Si se cruza el umbral SF, el protocolo de línea de la interfaz queda sin servicio.

El comando pos delay triggers path se introdujo en el software Cisco IOS® versión 12.0(16)S.

SONET MIB

Las interfaces SONET de Cisco también admiten la MIB SONET, que se define en Solicitud de comentarios (RFC) 1595 . El RFC utiliza la misma terminología para describir las condiciones de error en un circuito SONET que los estándares ANSI para SONET y en un circuito de Jerarquía digital sincrónica (SDH) según la especificación de la Unión Internacional de Telecomunicaciones (ITU-T) G.783.

Para obtener soporte SONET MIB en las interfaces Cisco POS y ATM sobre SONET, consulte estos recursos:

• Cisco MIBs: muestra las MIBs soportadas por plataforma, así como las cadenas de ID de objeto y los archivos .my para la MIB SONET.

• La familia Cisco 7000 y la serie 12000—Notas de la versión para la versión 12.0 S - Describe las mejoras en el soporte de Cisco para la MIB SONET.

Información Relacionada

• Páginas de soporte de hardware óptico
• Páginas de soporte de tecnología óptica
• Soporte Técnico - Cisco Systems

Historial de revisiones