Troubleshooting Physical Layer Alarms on SONET and SDH Links

Introduction

This document explains common SONET alarms and how to troubleshoot them.

Alarm surveillance uses two terms:

• State—Condition that is reported or detected. A SONET device enters a state when the device detects the occurrence of an event. A SONET device exits that state when the device no longer detects the event. This document discusses the loss of signal (LOS) and loss of frame (LOF) states.

• Indication—Prompted by a change of state. This indicates the presence of a condition. This document discusses the alarm indication signal (AIS), remote defect indicator (RDI), and far end receive failure (FERF) indications.

Active alarms or defects keep an interface in the down/down state. The process used to troubleshoot down/down SONET interfaces is similar to that for digital interfaces, such as T1 and T3.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

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

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Alarms at SONET's Layers

SONET equipment detects events and alarms at each of SONET's three layers -- section, line and path. Typically, a SONET device sends alarms both upstream and downstream in order to notify other devices of the problem condition.

Issue the pos report command in order to configure the alarms that the packet over SONET (POS) interface can activate.

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

The show controllers command displays the number of times that an alarm is declared and whether any alarms are active on a POS and ATM over SONET interface. This output was captured on a Gigabit Switch Router (GSR). The Active Defects section indicates what the local interface sees. The Active Alarms section indicates what the upstream device reports.

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

This sample output was also captured from a GSR. The LINK-3-UPDOWN message indicates that the physical-layer is up and that all active alarms are now clear. The LINEPROTO-5-UPDOWN message indicates that the line protocol is up; the line protocol on POS interfaces is Frame Relay, High-Level Data Link Control (HDLC) or 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

Note: In order to capture granular timestamps on log messages, configure the service timestamps log datetime msec command.

A router with ATM over SONET interfaces also reports active alarms with these log messages:

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

The "~" character indicates that the particular alarm is not active, and the absence of the ~ character indicates that the alarm is active. In this sample output, ~SLOF indicates that there are no section loss of frame errors. However, the interface experiences several other active alarms which include section loss of signal (SLOS) and line alarm indication signal (LAIS).

Alarm Indicators

Typically, a failure condition detected by a SONET device results in one or more error conditions sent both upstream and downstream on the network. An AIS is sent in order to alert downstream devices of a problem and in order to prevent consequential downstream failures or alarms from being raised. An RDI alarm is sent upstream as a control and feedback mechanism for the network. RDI was previously referred to as FERF.

The RDI is different from remote error indicator (REI). The REI communicates performance monitoring values, such as bit error rates.

Troubleshooting

Use this table in order to isolate and troubleshoot SONET alarms. Note the SONET layer at which errors and alarms are detected, when you troubleshoot. For example, perform an extended test of the end-to-end link if the POS interfaces report path-layer errors only. Also note what the upstream and remote devices see.

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

Troubleshoot with loopback Commands

The loopback test allows you to test the connection between the OC-3 interface and a remote device in order to troubleshoot, detect, and isolate equipment malfunctions.. The loopback command places an interface in internal loopback (also called local loopback) or line loopback mode, which enables test packets that are generated from the ping command to loop through a remote device or a cable. If the packets complete the loop, the connection is good. If not, you can isolate a fault to the remote device or the cable in the path of the loopback test.

With internal loopback, note:

• When you configure a loopback, ensure that you configure the interface for internal clocking with the clock source internal command. The framer waits for incoming valid frames with which to synchronize and uses theses frames to time its transmission, when configured for clock source line. With no receive frames, you have no timing to send frames.

• If you do a hardware loop -- in other words, you just loop the fiber back onto the interface -- make sure that you use an attenuator if you use a single mode interface. If you do not, you could blast the interface with too much power or even damage the optics on the card if it is a Long Reach card or if the transmit sends higher than its rated levels.

Configure an Interface for Internal Loopback

The default loopback setting is for no loopback. With internal (or local) loopback, packets from the router are looped back in the framer. Outgoing data is looped back to the receiver without actually being transmitted. Internal loopback is useful when you want to check that the POS interface works. In order to configure an interface for internal loopback, issue the loop internal command:

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

Configure an Interface for Line Loopback

The default loopback setting is for no loopback. With line loopback, the receive (Rx) fiber is logically connected to the transmit (Tx) optical fiber cable, so that packets from the remote router are looped back to it. Incoming data is looped around and retransmitted without actually being received. In order to configure an interface for line loopback, issue the loop line command:

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

Note: The loopback line command loops the signal before the SONET framer.

Configure SONET Delay Triggers

A trigger is an alarm which, when asserted, causes the line protocol to go down. These sections discuss line triggers and path triggers, which you configure with the pos delay triggers command.

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>

Line and Section Triggers

You use the pos delay triggers line command for Internet router POS interfaces connected to internally-protected Dense Wavelength Division Multiplexing (DWDM) systems (documented under CSCdm36033 and CSCdp65436 on Cisco 12000 series routers and CSCdr72941 on Cisco 7200 and 7500 series routers). This command is invalid for interfaces that are configured as APS working or protected. Normally, even a few microseconds of line- or section-level alarms (SLOS, SLOF, or LAIS) brings down the link until the alarm has been clear for ten seconds. If you configure holdoff, this link-down trigger is delayed for 100 ms. If the alarm stays up for more than 100 ms, the link is brought down as it is now. If the alarm clears before 100 ms, the link is not brought down.

By default, these line and section alarms are triggers for the line protocol to go down:

• Section loss of signal

• Section loss of frame

• Line alarm indication signal

The line protocol of the interface goes down without a delay when one or more of these alarms is asserted. You can issue the pos delay triggers line command in order to delay the line protocol of the interface from going down. You can set the delay from 0 to 511 ms. The default delay is set to 100 ms if you do not specify a time interval.

Path Level Triggers

These path alarms are not triggers by default. You can configure these path alarms as triggers and also specify a delay:

• Path alarm indication signal

• Path remote defect indication

• Path loss of pointer

You can issue the pos delay triggers path command in order to configure various path alarms as triggers and in order to specify an activation delay between 0 and 511 ms. The default delay value is 100 ms.

The pos delay triggers path configuration can also bring down the line protocol when the higher of the B2 and B3 error rates is compared with the signal failure (SF) threshold. If the SF threshold is crossed, then the line protocol of the interface goes down.

The pos delay triggers path command was introduced in Cisco IOS® Software Release 12.0(16)S.

SONET MIB

Cisco SONET interfaces also support the SONET MIB, which is defined in Request for Comments (RFC) 1595 . The RFC uses the same terminology in order to describe error conditions on a SONET circuit as ANSI standards for SONET and on a Synchronous Digital Hierarchy (SDH) circuit by the International Telecommunications Union (ITU-T) G.783 specification.

For SONET MIB support on Cisco POS and ATM over SONET interfaces, refer to these resources:

• Cisco MIBs—Lists the supported MIBs per platform as well as the object ID strings and the .my files for the SONET MIB.

• Cisco 7000 Family and 12000 Series—Release Notes for Release 12.0 S - Describes enhancements to Cisco support for the SONET MIB.

Related Information

• Optical Hardware Support Pages
• Optical Technology Support Pages
• Technical Support - Cisco Systems