Guest

Cisco 12000 Series Routers

Field Notice: *Expired* FN - 20080 - PRBS or SONET Payload Can Cause Linecard to Crash


Revised November 7, 2006

August 16, 2002

NOTICE:

THIS FIELD NOTICE HAS BEEN ARCHIVED AND IS NO LONGER MAINTAINED OR UPDATED BY CISCO.

THIS FIELD NOTICE IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE, WARRANTY OR SUPPORT. USE OF THE INFORMATION ON THIS FIELD NOTICE OR MATERIALS LINKED FROM THIS FIELD NOTICE IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS FIELD NOTICE AT ANY TIME.


Products Affected

Product

Comments

4OC12E/POS-IR-SC(=)

All revisions.

4OC12E/POS-MM-SC(=)

All revisions.

Problem Description

Running a pseudo-random binary sequence (PRBS) 2^23-1 test pattern on a port may result in brief (in the millisecond range) traffic interruptions to all other ports. If the pattern is received for an extended time the line card will reset, resulting in a longer outage.

Background

The PRBS 2^23-1 test pattern contains within it a sequence which triggers a false start-of-packet code to an ASIC which is shared between all ports as shown in the diagram below. The false start-of-packet code causes the ASIC to interrupt traffic briefly to all ports and generate a CPU interrupt. If the condition persists, the interrupts will eventually cause the CPU to be unable to maintain fabric ping which will result in the line card being reset by the route processor.

fn20080_h0wc62.gif

PRBS test patterns shorter than 2^23-1 will not cause this problem. PRBS test patterns longer than 2^23-1 will cause this problem. A garbage SONET payload may also cause this problem if it contains the triggering sequence. The exact triggering sequence is not known at this time. This field notice will be updated if and when that information becomes available.

Inter-POP troubleshooting can result in unexpected outages if one or both customers are unaware that PRBS test patterns will be run from a central location, such as a telco office. See the diagram below.

fn20080_h0wqxg.gif

Problem Symptoms

The error message signature associated with this phenomenon is given below. This error signature should be evaluated in the larger context of network operations before a positive diagnosis is made (was a PRBS pattern running on one of the ports when this error was logged).

%LCPOS-3-SOP: RX:UnexpectedSop. Source=0x4 (Framer), halt_minor0=0x8000

Where Source can be 0x2, 0x4, 0x8, 0x10, corresponding to port 0, 1,2,3. halt_minor0 can be 0x8000 (unexpected sop received) or 0x4000 (unexpected eop received).

Workaround/Solution

Cisco IOS? Software Release 12.0(21)ST2 and later have been modified so that if a port is receiving a signal which causes the framer to generate a false start-of-packet code and a CPU interrupt, the CPU will command the afflicted framer to go into drop mode for 500 msec. When the framer is in drop mode subsequent false start-of-packet codes are not sent to the shared ASIC and CPU interrupts are no longer generated.

Note: The initial false start-of-packet code will cause a brief interruption in traffic on all ports in the millisecond range.

fn20080_h0wcda.gif

If the offending traffic pattern is still present after the framer comes out of drop mode, or within 10 seconds after having come out of drop mode, another false start-of-packet code will be passed to the framer, another CPU interrupt generated and the cycle described above will repeat except that the CPU will command the framer to stay in drop mode for twice as long each time up to a maximum of 8 seconds. If the offending traffic pattern is absent for more then 10 seconds, the drop mode timer resets to 500 msec.

Assuming the offending traffic pattern is present for an extended time, brief interruptions, in the millisecond range, will occur on all ports as shown below (along with CPU interrupts) and continuing for every 8 seconds thereafter.

fn20080_h0tlao.gif

The overall effect of this software fix is to prevent the CPU from being overloaded with interrupts. The processor is easily able to keep up with interrupt requests coming in at the rate shown in the above diagram. This prevents fabric ping timeouts and the line card being reset by the route processor. Minor interruptions to traffic on all ports (in the millisecond range) will still occur however.

The "-B" versions of the affected line cards will not exhibit this problem due to a modification to the shared ASIC. An alternative solution is therefore to replace the non-B versions of the line card with "-B" versions. Customers who wish to do this should create an return material authorization (RMA), requesting the "-B" product (referencing this field notice). RMAs should be coded as follows:

Service Level: Mfg New - 3rd Bus Day NON BILLABLE

Failure Class: Administrative Request

Failure Code: Field Notice Alert

The table below provides the Product IDs for the -B line cards. Note these Product IDs do not have an "E" in them.

Non "-B" Product ID

"-B" Product ID

4OC12E/POS-IR-SC(=)

4OC12/POS-IR-SC-B(=)

4OC12E/POS-MM-SC(=)

4OC12/POS-MM-SC- B(=)

DDTS

To follow the bug ID link below and see detailed bug information, you must be a registered user and you must be logged in.

DDTS

Description

CSCdx04487 (registered customers only)

LCPOS-3-SOP: RX:UnexpectedSop. Source=0x4 (Framer); w/ framer rev 4

For More Information

If you require further assistance, or if you have any further questions regarding this field notice, please contact the Cisco Systems Technical Assistance Center (TAC) by one of the following methods:

Receive Email Notification For New Field Notices

Product Alert Tool - Set up a profile to receive email updates about reliability, safety, network security, and end-of-sale issues for the Cisco products you specify.