Last FEAC code received: OOF

Unanswered Question
Jan 12th, 2010

When I do 'sh controllers serial 1/0' I get the OOF message at the very bottom.  I can't find much on google about this error or how to troubleshoot it.  When I clear the counters on the interface the message remains.  What is the proper way to clear this message?  Or does this mean it is an ongoing issue that can't be cleared because it continues to lose framing?  TIA

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Giuseppe Larosa Tue, 01/12/2010 - 10:09

Hello,


OOF = out of frame delineation


it indicates that the receiver is not capable to recognize the frame structure caused by line code errors and/or clocking errors.


I would suggest you to post the whole sh controller serial 1/0 in the output interpreter if your CCO account has enough rights


you can find it here


https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl


or you can post here in the forums


Hope to help

Giuseppe

snickered Tue, 01/12/2010 - 10:22

That tool never works for me.  Here's my 'sho controllers s1/0'.


M2T-T3+ pa: show controller:

PAS unit 0, subunit 0, f/w version 3-93, rev ID 0x2800001, version 3

idb = 0x71D9D6C, ds = 0x71DAEB4, ssb=0x71DB278

Clock mux=0x30, ucmd_ctrl=0x0, port_status=0x1

Serial config=0xA, line config=0x1B0202

maxdgram=4584, bufpool=128Kb, 256 particles


   rxLOS inactive, rxLOF inactive, rxAIS inactive

   txAIS inactive, rxRAI inactive, txRAI inactive

line state: up

cable type : T3  cable, received clockrate 44201430


base0 registers=0xE0000000, base1 registers=0xE0002000

mxt_ds=0x8A7EE0C, rx ring entries=124, tx ring entries=254

statring=0x38364840, statr shadow=0x71FDB30, stat_head=289

rxring=0x38363840, rxr shadow=0x71FD4FC, rx_head=94

txring=0x384C7640, txr shadow=0x71FE764, tx_head=10, tx_tail=10, tx_count=0

throttled=0, enabled=0

halted=0, last halt reason=0

Microcode fatal errors=0

rx_no_eop_err=0, rx_no_stp_err=0, rx_no_eop_stp_err=0

rx_no_buf=0, rx_soft_overrun_err=49, dump_err= 0, bogus=0, mxt_flags=0x2C

tx_underrun_err=0, tx_soft_underrun_err=0, tx_limited=1(64)

tx_fullring=0, tx_started=1371222963, mxt_flush_count=0

rx_int_count=1551990381, tx_int_count=1371222963

   Framing is c-bit, Clock Source is Line

   Bandwidth limit is 44210, DSU mode 1, Cable length is 220

   rx FEBE since last clear counter 0, since reset 1251926

   Data in current interval (71 seconds elapsed):

     0 Line Code Violations, 0 P-bit Coding Violation

     0 C-bit Coding Violation

     0 P-bit Err Secs, 0 P-bit Sev Err Secs

     0 Sev Err Framing Secs, 0 Unavailable Secs

     0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs

  Data in Interval 1:

     0 Line Code Violations, 0 P-bit Coding Violation

     0 C-bit Coding Violation

     0 P-bit Err Secs, 0 P-bit Sev Err Secs

     0 Sev Err Framing Secs, 0 Unavailable Secs

     0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs

  Data in Interval 2:

     0 Line Code Violations, 0 P-bit Coding Violation

     0 C-bit Coding Violation

     0 P-bit Err Secs, 0 P-bit Sev Err Secs

     0 Sev Err Framing Secs, 0 Unavailable Secs

     0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs

  Data in Interval 3:

     0 Line Code Violations, 0 P-bit Coding Violation

     0 C-bit Coding Violation

     0 P-bit Err Secs, 0 P-bit Sev Err Secs

     0 Sev Err Framing Secs, 0 Unavailable Secs

     0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs

  Data in Interval 4:

     0 Line Code Violations, 0 P-bit Coding Violation

     0 C-bit Coding Violation

     0 P-bit Err Secs, 0 P-bit Sev Err Secs

     0 Sev Err Framing Secs, 0 Unavailable Secs

     0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs

  Data in Interval 5:

     0 Line Code Violations, 0 P-bit Coding Violation

     0 C-bit Coding Violation

     0 P-bit Err Secs, 0 P-bit Sev Err Secs

     0 Sev Err Framing Secs, 0 Unavailable Secs

     0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs

  Data in Interval 6:

     0 Line Code Violations, 0 P-bit Coding Violation

     0 C-bit Coding Violation

     0 P-bit Err Secs, 0 P-bit Sev Err Secs

     0 Sev Err Framing Secs, 0 Unavailable Secs

     0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs

  Data in Interval 7:

     0 Line Code Violations, 0 P-bit Coding Violation

     0 C-bit Coding Violation

     0 P-bit Err Secs, 0 P-bit Sev Err Secs

     0 Sev Err Framing Secs, 0 Unavailable Secs

     0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs

  Data in Interval 8:

     0 Line Code Violations, 0 P-bit Coding Violation

     0 C-bit Coding Violation

     0 P-bit Err Secs, 0 P-bit Sev Err Secs

     0 Sev Err Framing Secs, 0 Unavailable Secs

     0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs

  Data in Interval 9:

     0 Line Code Violations, 0 P-bit Coding Violation

     0 C-bit Coding Violation

     0 P-bit Err Secs, 0 P-bit Sev Err Secs

     0 Sev Err Framing Secs, 0 Unavailable Secs

     0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs

  Data in Interval 10:

     0 Line Code Violations, 0 P-bit Coding Violation

     0 C-bit Coding Violation

     0 P-bit Err Secs, 0 P-bit Sev Err Secs

     0 Sev Err Framing Secs, 0 Unavailable Secs

     0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs

   Total Data (last 10 15 minute intervals):

     0 Line Code Violations, 0 P-bit Coding Violation,

     0 C-bit Coding Violation,

     0 P-bit Err Secs, 0 P-bit Sev Err Secs,

     0 Sev Err Framing Secs, 0 Unavailable Secs,

     0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs


   No alarms detected.

   Last FEAC code received: OOF

Giuseppe Larosa Tue, 01/12/2010 - 11:28

Hello Snickered,

to be honest output intepreter feedback on this sh controller is poor.


I've looked for troubleshooting documents about T3 here are some links:


http://www.cisco.com/en/US/tech/tk713/tk628/technologies_tech_note09186a008034418d.shtml#maintopic1


http://www.cisco.com/en/US/tech/tk713/tk628/technologies_tech_note09186a0080344194.shtml


http://www.cisco.com/en/US/tech/tk713/tk628/technologies_tech_note09186a008034bdd8.shtml


FEAC should be far end = other side


it is a management feature actually, a link to DS3 standard explanation


DS3 remote-line loopback (via Far End Alarm and Control [FEAC] codes per American National Standards Institute [ANSI] T1.107a)


http://www.cisco.com/en/US/prod/collateral/modules/ps2797/ps4909/product_data_sheet09186a008010fba2_ps282_Products_Data_Sheet.html



http://www.teracomm.com/appnotes/whitepapers/DS3%20Fundamentals.pdf


So I would see if you manage the other side you should look at the device on the other side, if you don't manage the other end of DS3 link you should contact the WAN provider.


Hope to help

Giuseppe

rigoel Tue, 01/12/2010 - 12:35

Hey Snickered,


We are getting FEBE at the end of the sh controllers output and here

FEBE means Far End Bit Error.

This generally comes up when we have problems ( Circuit ) with the Provider.

Moreover , as it is not going away with the clear counters command, would really mean that we are running into Line Problems with the Provider.

At this point, the best deal here would be know the source of these errors.

Thus, I would suggest you to do a T3 Loopback Test:

During the Loopback Test the Controller t3 output should be completely clean and error free.


Here is a link to do the same:


T3 Error Events Troubleshooting and its related loopback
http://www.cisco.com/en/US/tech/tk713/tk628/technologies_tech_note09186a008034418d.shtml#maintopic4


Now, this loopback test is of two types:

#Hardware Loopback Test

#Software Loopback Test


In case, if you want to go for Hardware T3 test, then you have to make a loopbcak cable where the Tx- and the Rx- pins are bound to each other.

If that is not possible, we can try doing a lopback test:

For the same , we need to have the encapsulation set to hdlc, followed by the command ie :


#loopback diag

Under the Controller.


Therafter, clear the counters, and check the output of the sh controllers output.

That should be 100% clean.

So this loopback test is the finest way to know the source of the errrors/alarms.

In case if this test comes out clean that would really mean that we have no problems from the Cisco Side, and there is definitely a problem with the

Circuit line which needs to be looked at.


Hope this helps!


Regards,

Rishika Goel

Paolo Bevilacqua Tue, 01/12/2010 - 15:19

Rigoel,


there is no problem, the circuit works perfectly:


   No alarms detected.


and I have indicated the meaning of the message in my other post on this thread.

Giuseppe Larosa Wed, 01/13/2010 - 03:08

Hello Rigoel,

Paolo is absolutely right: no alarms detected and the messsage is about last alarm received in the past

Paolo: rated as deserved


Sorry for some confusion, I've focused on finding what FEAC is and I've missed that was about the past



Hope to help

Giuseppe

Paolo Bevilacqua Tue, 01/12/2010 - 12:30

Circuit is fine and you need not to do anything.


The message reportes a previous anomaly, not the current status, that is "no alarms detected".

snickered Thu, 01/14/2010 - 11:23

One side (SITEB) of the point-to-point just showed some errors.  Here's what they look like:

sh controllers:


  Data in Interval 10:

     0 Line Code Violations, 5 P-bit Coding Violation

     5 C-bit Coding Violation

     1 P-bit Err Secs, 0 P-bit Sev Err Secs

     0 Sev Err Framing Secs, 20 Unavailable Secs

     1 Line Errored Secs, 1 C-bit Errored Secs, 0 C-bit Sev Err Secs

sh interfaces:


  Last input 00:00:00, output 00:00:00, output hang never

  Last clearing of "show interface" counters 2d03h

  Input queue: 0/75/0/1025 (size/max/drops/flushes); Total output drops: 2722

  Queueing strategy: Class-based queueing

  Output queue: 0/1000/0 (size/max total/drops)

  5 minute input rate 520000 bits/sec, 230 packets/sec

  5 minute output rate 2347000 bits/sec, 322 packets/sec

     20935554 packets input, 1426055651 bytes, 8 no buffer

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

              0 parity

     86838 input errors, 85508 CRC, 0 frame, 1031 overrun, 6 ignored, 299 abort

     22527028 packets output, 292449697 bytes, 0 underruns

     0 output errors, 0 applique, 0 interface resets

     258 unknown protocol drops

     0 output buffer failures, 0 output buffers swapped out

     2 carrier transitions

   rxLOS inactive, rxLOF inactive, rxAIS inactive

   txAIS inactive, rxRAI inactive, txRAI inactive



Now, on SITEA there are no errors at all in 'sh controllers' nor 'sh interfaces'. 

sh controllers:


   Total Data (last 24 hours)

     0 Line Code Violations, 0 P-bit Coding Violation,

     0 C-bit Coding Violation,

     0 P-bit Err Secs, 0 P-bit Sev Err Secs,

     0 Sev Err Framing Secs, 0 Unavailable Secs,

     0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs

sh interfaces:


  Last input 00:00:00, output 00:00:00, output hang never

  Last clearing of "show interface" counters 2d04h

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 646

  Queueing strategy: Class-based queueing

  Output queue: 0/1000/0 (size/max total/drops)

  5 minute input rate 2935000 bits/sec, 361 packets/sec

  5 minute output rate 564000 bits/sec, 249 packets/sec

     22886427 packets input, 468243936 bytes, 0 no buffer

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

              0 parity

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     21276093 packets output, 1527862884 bytes, 0 underruns

     0 output errors, 0 applique, 0 interface resets

     0 unknown protocol drops

     0 output buffer failures, 0 output buffers swapped out

     0 carrier transitions

   rxLOS inactive, rxLOF inactive, rxAIS inactive

   txAIS inactive, rxRAI inactive, txRAI inactive


The carrier says it's coming from SITEA.  I don't doubt it's coming from SITEA but is it necessarily my equipment?  Should I be able to see errors on the SITEA router?  TIA.

Actions

This Discussion