Fiber module failure

Unanswered Question

Last night I was implementing Diffserv 46 QoS on my Cisco 2821 that has an HWIC-1GE-SFP card and a GLC-ZX-SM fiber module. When we inserted the commands, and applied the service policy to the interface, we immediately dropped network connectivity. The interface went in to an up/down state and would not come back. We went as far as removing the commands and rebooting the router. We have been told that the GLC-ZX-SM module failed. Does anyone know what could cause this?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
scottmac Tue, 08/07/2007 - 06:22

If this was done in a lab environment, where the devices were a few feet apart instead of a few kilometers apart, you may have burned out th ereceiver if you didn't use some sort of attenuation between the devices.

ZX is a pretty long haul gizmo. Even if the units were some distance apart, did you measure to see if the signal was within the operational envelope / optical budget between the two devices?

Some additional details would be good...

Thanks / Good Luck



This was a production router with a 100Mb Gig-E handoff from the ISP. The other end of the fiber is 27 miles away. We have been in production with this router for over a year and there have been no reboots until we backed out of the commands last night when the interface went Up/Down... That is what has me concerned. All that we added was the QoS commands then the interface went down...



scottmac Tue, 08/07/2007 - 07:27

Can you verify with the ISP to make sure that your interface to their system is still up?

Perhaps your QOS config generated something that they interpreted as an invalid profile, or an attack profile ... something that would cause their protection / security systs to engage and drop or blackhole you traffic.

If you haven't checked with them, it might be a good starting point, since you said you've reset the router back to its original configuartion.

Good Luck



We contacted the ISP and they did not see any errors or malicious profile. They administratively shut down the interface and brought it back up several times. Each time the interface would go UP/UP then immediately revert back to UP/DOWN. That is another odd occurance, the interfaces would see each other as UP, but the line protocol would be DOWN...



Pavel Bykov Tue, 08/07/2007 - 07:57

That's not right... second layer would not be down just because of a QoS command.

We had similar problem with 6506<>7206 connection, also related to QoS command.

The trick is, that it's not the QoS command that causes the problem, but the connection is Automatic in some way that makes it not work after even short disruption or reboot.

My problem was with flow control. Try enabling RX/TX flow control.


This Discussion