Table of Contents
Advertisement
Chapter 3 – Software
Statistics & Logs > Line Interface Status
working properly and that the problem is at T1/E1 equipment down the line from (remote to) the MultiAccess.
The front panel LEDs will reflect the LS on solid, with the LA and LC off.
is reported by the line interface when it is unable to synchronize with the incoming
Loss of Frame Alignment -
signal. This is most likely due to a timing problem on the line or a mismatch in framing format settings. The
front panel LEDs will reflect the LA flashing, with the LC and LS off.
is equal to AIS (Alarm Indication Signal). Like the yellow alarm, it is a signal the MultiAccess
Blue Alarm -
receives from the line and indicates the problem is remote to the MultiAccess. The AIS pattern is a constant
stream of unframed ones. AIS is usually an indication of an end to end physical or logical failure and that it is
most likely on the other side of the immediate Telco equipment we are communicating with. The front panel
LEDs will reflect the LA flashing, with the LC and LS off.
Regarding the various bit error counters, these counters will not increment on a clean T1\E1 line. If these types
of errors do occur, these fields are not updated on this screen. Instead, any change to these counters will be
entered into the kernel log file (messages file) as FALC events (as the changes occur). Bit errors can cause
individual modem problems (no connects, sluggish performance and disconnects). Please Note, a change in
Layer 1 status are also written to the log file as they occur.
The following are some example messages.
The log file will contain the following sequence of messages when a red alarm condition occurs.
Jul 28 14:30:31 multiaccess kernel: FALC 800:
Jul 28 14:30:31 multiaccess kernel: fech = 0, fecl = 4
Jul 28 14:30:31 multiaccess kernel: cvch = 0, cvcl = 0
Jul 28 14:30:31 multiaccess kernel: cech = 0, cecl = 0
Jul 28 14:30:31 multiaccess kernel: ebch = 0, ebcl = 0
Jul 28 14:30:31 multiaccess kernel: bech = 0, becl = 0
Jul 28 14:30:31 multiaccess kernel: Red Alarm on falc 800
The following sequence is an example of logged messages when the line recovers from a red alarm condition.
Jul 28 14:32:31 multiaccess kernel: Red Alarm Recovered on falc 800
Jul 28 14:32:31 multiaccess kernel: Loss Frame Alignment but not LOS on falc 800
Jul 28 14:32:31 multiaccess kernel: Link is active on falc 800
The following example displays a burst of line code bi-polar violation errors.
Jul 28 14:35:17 multiaccess kernel: FALC 800:
Jul 28 14:35:17 multiaccess kernel: fech = 0, fecl = 0
Jul 28 14:35:17 multiaccess kernel: cvch = 0, cvcl = 3
Jul 28 14:35:17 multiaccess kernel: cech = 0, cecl = 0
Jul 28 14:35:17 multiaccess kernel: ebch = 0, ebcl = 0
Jul 28 14:35:17 multiaccess kernel: bech = 0, becl = 0
Jul 28 14:35:18 multiaccess kernel: FALC 800:
Jul 28 14:35:18 multiaccess kernel: fech = 0, fecl = 0
Jul 28 14:35:18 multiaccess kernel: cvch = 0, cvcl = 2
Jul 28 14:35:18 multiaccess kernel: cech = 0, cecl = 0
Jul 28 14:35:18 multiaccess kernel: ebch = 0, ebcl = 0
Jul 28 14:35:18 multiaccess kernel: bech = 0, becl = 0
The letters ch is count high and cl is count low, fe is frame errors, cv is bi-polar violations, ce is crc errors, eb is
errored blocks and be is bursty errors.
MultiAccess Communications Server MA30120 User Guide
106
Advertisement
Table of Contents
