CWDM-SFPs und CWDM-MUX-8A-Multiplexer Back-to-Back testen, nachdem Links err-disabled gegangen sind
Im Rechenzentrum des Fragestellers hörten mehrere Cisco-CWDM-SFP/GBIC-Links auf zu funktionieren: Manche Ports gingen err-disabled (bei einem mit link-flap als Ursache), andere zeigten schlicht notconnect. Die Fehlersuche umfasste shut/no shut, Neustecken der Module, Umstecken der CWDM-SFPs auf andere Ports, Tausch der Patchkabel und Prüfen des Interface-Medientyps, aber jeder Port landete bei notconnect. Im Verdacht standen die CWDM-MUX-8A-Multiplexer, und der Fragesteller wollte mit zwei übrigen Muxen einen Punkt-zu-Punkt-Laboraufbau bauen, um Optik und Muxe auszuschließen, und fragte nach optischen Pegeln, minimaler Faserlänge, wie man ein Catalyst-Interface zum Testen loopt, und ob sich ein OTDR am Mux-Monitor-Port im Produktivbetrieb einsetzen lässt.
- Hardware: Cisco-Catalyst-Switch (Modell nicht genannt)
- Transceiver: Cisco-CWDM-SFP/GBIC-Module (Wellenlängen nicht genannt), CWDM-MUX-8A-Multiplexer
- Formfaktor: SFP, GBIC
Symptome / Meldungen:
port err-disabled (link-flap)
notconnect
several CWDM links failed at once
Comments 3
Für zwei CWDM-MUX8-A-Multiplexer im Back-to-Back-Aufbau etwa 10 dB Dämpfung einfügen: +5 dBm max. TX minus -7 dBm max. RX bedeutet, dass 12 dB Verlust gebraucht werden, die beiden Multiplexer tragen nur 2 x 2,2 dB bei, es bleiben 7,6 dB zum Ergänzen. CWDM-Empfänger sind breitbandig, jede CWDM-Wellenlänge kann also von jedem CWDM-Transceiver empfangen werden.
TX auf RX jedes CWDM-Moduls mit einem Patchkabel und einem Dämpfungsglied loopen (TX etwa +3 dBm gegenüber maximal -7 dBm RX); 'no errdisable detect cause loopback' verwenden, damit der Catalyst den geloopten Port nicht err-disabled. Zwei CWDM-Optiken derselben Wellenlänge lassen sich auch mit Dämpfungsgliedern back-to-back verbinden, da die Empfänger 1450-1620 nm akzeptieren.
Von einem SFP in ein anderes SFP am selben Switch zu senden zeigt wahrscheinlich Link, ohne den Empfänger zu schädigen; siehe Ciscos SFP-Troubleshooting-Guide. Ein OTDR am Mux-Monitor-Port eines Live-Netzes einzusetzen ist unklug, weil sein breitbandiger ~1550-nm-Puls in aktive Kanäle übergreifen kann.