Disabled txpower on some ports when fully populating WSC4506E with WS-X4640-CSFP-E on bootup
We have a issue where some CSFP's, every third or so, have disabled txpower on bootup (-40dBm in show int tran ) if you populate a 4506E chassis with 4 or more WS-X4640-CSFP-E. "hw-module module 2 reset" brings up the card in functioning state.
Swapping the LC's does not help, tested on several boxes and with different types of power supplies.
The ports can be completely unconfigured and it still happens. Every port have the same configuration.
Have you found a solution to this? I see the same isssue on WS-C4503-E chassis and WS-X45-SUP8-E supervisor and WS-X4640-CSFP-E linecards.
When we move the linecards to a Sup6 device everything works as normal so I don's suspect there is something wrong with the hardware.
Do you have problems with negotiating speed on the working Gig interfaces as well? I need to set 'speed nonegotiate' on the interfaces to get link, but 'sh int transceiver' shows both optical RX og TX signal.
Hi Roger, We are currently waiting for Cisco TAC to verify this issue, they are waiting for hardware for their labs. Maybe in the beginning of December there is acknowledgement from Cisco on the issue...
I have confirmation from another service provider that they are having the same issues, they have also a TAC case going on, but afaik, without progress.
I can confirm that these cards/SFP's seems to have a issue when running "speed nonegotiate", it seems to link up with itself. Quite random. I have not followed up this issue.
EDIT: The self linkup happens when there is no cable connected, I suspect there is not enough isolation in the SFP between tx laser and rx sensor.
We are seeing the same thin on our 4506E chassies with SUP7E and the 4640 linecards.
The problem always appears on port 3 and then on every 4th port as seen in the post above.
We've had some succes resolving this by either toggling the adminstate of the ports or by resetting the whole linecard. At the moment though we are in a situation where these tricks doesn't help at all.
I've opened a TAC-case on the issue but with no feedback yet.
Has anyone got any explanation from Cisco regarding this behavior?
We would have to reboot the device and as soon as supervisor comes up we should enabled debugs (line cards are still booting) and stop debugs once some of the ports go down. At that time it would be helpful to gather "show int tran" to see which ports are impacted.
Additionally I would suggest to increase logging buffer size to capture all debugs and disable logging debug output to both console and monitor.
Can you please advise if you can proceed with above steps?"
The Cisco EPN system incorporates a network architecture designed to consolidate multiples services on a single Multiprotocol Label Switching (MPLS) transport network. This network is designed primarily based on Application Engineered...
Internet security is important with the increasing attacks that are happening every day. Many internet and browsing security solutions exist, but some are not very easy to use or maybe the question is how can I enable them?
Cisco Software Manager Server
This document describes the programmatic interfaces, RESTful APIs, which are supported by Cisco Software Manager Server (CSM Server).
CSM Server supports a set of finite RESTful APIs. The fir...