This document explains common SONET alarms and how to troubleshoot
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)
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.
There are no specific requirements for this document.
This document is not restricted to specific software and 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.
Technical Tips Conventions for more information on document
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
Issue the pos report command in order to
configure the alarms that the packet over SONET (POS) interface can
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
RTR12410-1#show controller pos 1/0
LOF = 1 LOS = 1 BIP(B1) = 31165
AIS = 1 RDI = 0 FEBE = 0 BIP(B2) = 0
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
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
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
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).
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.
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.
Alarm Type and Severity
Conditions That Cause Alarm to be Triggered
Section Loss of Signal (SLOS)
A SONET link must see a certain number of digital bit
transitions (from 1 to 0 and 0 to 1) in order to ensure proper synchronization.
LOS is declared when no bit transitions are detected on the incoming signal
(before descrambling) for 2.3 to 100 microseconds. The LOS defect is cleared
after a 125-microsecond interval (one frame) during which no LOS defect is
Note: LOS typically occurs in back-to-back lab setups because the
receiver is saturated with too much light, particularly when long-reach single
mode interfaces are used. Try to attenuate the signal.
Check the fiber optic cable in order to make sure it is
Verify that the local fiber optic cable is not damaged. Look
for breaks or physical abnormalities.
Make sure that the remote end of the fiber optic cable is
connected, undamaged and that the remote port is configured
Try a soft loopback with the loopback
Try a hard loopback. Connect the transmit to receive with a
single fiber strand.
Determine whether the POS interface simply receives too
little or too much light.
Section Loss of Frame (SLOF)
The A1 and A2 bytes in the section overhead provide frame
alignment with a particular bit pattern. A receiving interface declares LOF
after it detects errors in the framing pattern for three milliseconds. LOF is
cleared when two consecutive valid A1/A2 framing patterns are received.
Check the fiber optic cable in order to make sure the cable
is plugged in and is not damaged.
Ensure the framing format on the port matches the format
configured on the line:
router(config-if)# [no] pos framing-sdh
Alarm Indicate Signal - Line (LAIS)
LAIS is sent by the section terminating equipment (STE) to
alert the downstream line terminating equipment (LTE) that a LOS or LOF defect
has been detected on the incoming SONET section. Upstream STE generates line
AIS to downstream LTE by setting bits 6, 7, and 8 of the K2 byte to 111.
Verify that the remote configuration is
Check the line status at the remote end of the
Remote Defect Indication - Line (LRDI)
RDI alarms are always reported upstream from the detecting
device. LRDI specifically comes back in the K2 bits 6-8 and overrides any
existing Automatic Protection Switching (APS) modes: (APS 1+1) or APS status
(BLSR). AIS-L is also sent in bits 6-8 and is generally sent from a SONET
regenerator or other STE.
RDI—Line problems arise from the remote interface.
Check the remote site for alarm conditions.
Alarm Indicate Signal - Path (PAIS)
An upstream LTE that receives LAIS then sends path AIS to the
downstream PTE by setting H1 and H2 bytes. The purpose is to alert the
downstream PTE of a defect on the upstream LTE's incoming line
This is sent by a site that has received LAIS. This is a minor
warning, and no action needs to be taken except to monitor the far end.
If the alarms are persistent, verify the interface
configurations on both ends of the trunk.
Remote Defect Indication - Path (PRDI)
Path Remote Defect Indicator (PRDI) is used only at the path
level. A problem at the path layer prompts PAIS to be sent downstream and PRDI
to be sent back upstream to let the traffic provider know that there is a
problem with their circuit down stream.
A PRDI alarm usually indicates a problem two sites away. If the
alarm is persistent, check the alarm status of neighboring sites, beginning
with the nearest neighbor.
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
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
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
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
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
Note: The loopback line command loops the signal
before the SONET framer.
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
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
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:
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.
These path alarms are not triggers by default. You can configure these
path alarms as triggers and also specify a delay:
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
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.
Cisco SONET interfaces also support the SONET MIB, which is defined in
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:
MIBs—Lists the supported MIBs per platform as well as the object ID
strings and the .my files for the SONET MIB.
7000 Family and 12000 Series—Release Notes for Release 12.0 S -
Describes enhancements to Cisco support for the SONET