Synchronization Loss on Data Interface

[taelon_x7]

Hello,

We are in the process of turning up two new sites and are using 15454 MSTP platform with DWDM between sites. The connectivity is a mixture of 10gb FibreChan, 10gb Ethernet and 1gb Ethernet. The problem we are having is that after all of the 10gb FibreChan circuits were turned online, we started to recieve Synchronization Loss on Data Interface errors on multiple of the Fibre Chan interfaces on the OTU2 cards. The TX power on the client port is reporting -40 db which is very odd. We have tried swapping optics with known good optics and replacing all of the client side fiber. We did have 3 of the 8 fibre chan trunks up and 5 of them were reporting this error. We swapped a known good OTU2 card with one of the ones reporting the Synchronization Loss on Data Interface error and the error went away. We swapped another OTU2 card that was having the same Synchronization Loss on Data Interface error and it too resolved the issue.

We now have 5 of the 8 trunks online with no errors. Could we possibly have this many bad OTU2 cards or could it be something else?

[dokirk]

Hi Taelon,

Are you only having the issue with a specific payload type or both FC & GE?

Are your alarms on the trunk or client ports?

Have you tried softreseting the OTU2?

Hope this helps,

DMK

[taelon_x7]

FYI - Just wanted to update this in case someone else ran across this issue. Apparently it is a bug and physically reseating the card will fix the issue. Doing a soft reset will not fix this, you must physically reseat the card.

[fazmibakar]

how to physically reset the card?is it by pulling the card?

[supoonia]

yeah physicaly pull it out and put it back.

if all is fine than SYNCLOSS on OTU2_XP is bad card not even bad XFP. :-)

[supoonia]

i know its too late, but just posting here known reason for SYNCLOSS on OTU2_XP.

SYNCLOSS on OTU2_XP Client Ports

Introduction:

SYNCLOSS alarm mean Loss of Signal Synchronization. It happens when the end to end signals are not synchronized. It can be possible due to the synchronized data coming from an end devices from one end and un-synchronized from another end.

Prerequisites:

Understanding of Cisco MSTP

Different causes of these alarms:

• Fiber continuity with the client devices.
• PPMs configured with different traffic rates.
• Bad XFP or BAD hardware
• FPGA not updated on card.
• Software defect (CSCuj35600 ) change in FEC results in this alarm.

Troubleshooting:

• First check optical power levels on client ports and trunk ports they should be within specifications.

        Link to check XFPs/SFPs specification

        https://www.cisco.com/en/US/docs/optical/spares/gbic/guides/b_ons_pluggables.pdf

• Check frame rates on both client ports.
• Check end to end connectivity of client device to client device, maybe by doing shut on their ports and checking if we are getting loss of signal.
• There is a software defect in 9.221, look for software version of node.
• FPGA not updated, this case is seen with 9.60 releases, so make all ports on OTU2_XP out of service, and then click on FORCE FPGA UPDATE.
• If all above are not applicable, go for a change of XFP and OTU2_XP, change will be on the card having alarm.

[supoonia]

Introduction:

SYNCLOSS alarm mean Loss of Signal Synchronization. It happens when the end to end signals are not synchronized. It can be possible due to the synchronized data coming from an end devices from one end and un-synchronized from another end.

Prerequisites:

Understanding of Cisco MSTP

Different causes of these alarms:

• Fiber continuity with the client devices.
• PPMs configured with different traffic rates.
• Bad XFP or BAD hardware
• FPGA not updated on card.
• Software defect (CSCuj35600 ) change in FEC results in this alarm.

Troubleshooting:

• First check optical power levels on client ports and trunk ports they should be within specifications.

        Link to check XFPs/SFPs specification

        https://www.cisco.com/en/US/docs/optical/spares/gbic/guides/b_ons_pluggables.pdf

• Check frame rates on both client ports.
• Check end to end connectivity of client device to client device, maybe by doing shut on their ports and checking if we are getting loss of signal.
• There is a software defect in 9.221, look for software version of node.
• FPGA not updated, this case is seen with 9.60 releases, so make all ports on OTU2_XP out of service, and then click on FORCE FPGA UPDATE.
• If all above are not applicable, go for a change of XFP and OTU2_XP, change will be on the card having alarm.

[Carl Lindahl]

Does putting the card OOS, then doing FPGA upgrade and then IS fix this bug? seems to be seen quite often on OTU2-XP Cards even with newer software.