CRS226 meldt no-link en sfp-rx-lose yes op een Cisco-gecodeerde SFP-10G-LR-uplink
We hebben een kleine aggregatielocatie overgenomen en een van de 10G-uplinks is niet meer opgekomen sinds de module erin vervangen werd. De module staat vermeld als incompatibel met de CRS226, dus daar viel de verdenking als eerste op, maar de waarden zien er voor mij niet uit als een geweigerde module.
- MikroTik CRS226 op de aggregatielocatie, module in sfp-sfpplus1
- Fiberworks SFP-10G-LR, Cisco-gecodeerd
- single-mode paar naar de externe locatie, onderweg door twee panelen gepatcht
/interface ethernet monitor sfp-sfpplus1
status: no-link
sfp-rx-lose: yesTemperatuur en voedingsspanning in dezelfde output lezen helemaal normaal, en de module wordt duidelijk gedetecteerd - dit is geen uitlezing van een lege cage.
Al gedaan aan onze kant:
- de module opnieuw geplaatst en beide connectoren gereinigd
- naar de andere SFP+-poort verplaatst, identieke output
- de poortconfig gecontroleerd, niets geforceerd, niets uitgeschakeld
Dus wat is het: weigert de CRS226 stilletjes een Cisco-gecodeerde module en meldt hij die als no-link, of betekent sfp-rx-lose wat ik denk dat het betekent en moet ik iemand naar het verre eind sturen?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Je eigen output heeft de compatibiliteitsvraag al beantwoord. Een module die de switch geweigerd had, zou helemaal geen temperatuur en spanning melden - een volledige monitoruitlezing betekent dat de CRS226 de module heeft uitgelezen en er prima mee praat. En
sfp-rx-lose: yesis de eigen loss-of-signal-indicatie van de module: hij ziet geen licht op de ontvangstvezel. Geen licht erin, geen link, wat de codering ook zegt.Dus dit is een infrastructuurprobleem, geen compatibiliteitsprobleem. De volgorde waarin ik het zou aanpakken:
Voor wat het waard is, datzelfde moduletype draait hier al maanden in een CRS226 richting een CCR, dus de combinatie zelf is niet het probleem.
Wat zit er aan het verre eind, en toont die kant zijn poort als up? Als de externe zender aan staat, zou je wat ontvangstvermogen verwachten in plaats van een pure loss-of-signal.
Twee goedkope controles voor iemand erheen rijdt. Wissel de twee strengen om bij je patchpaneel en kijk of de melding blijft staan waar hij stond. En laat de verre kant zijn eigen module uitlezen: melden beide kanten verlies van ontvangst, dan is het paar ergens in het midden kapot, of heeft iemand de verkeerde strengen gepatcht op een van die panelen.
De moeite waard om twee faalmodi uit elkaar te houden terwijl je daar bent. Helemaal geen licht is wat jij hebt, en dat is de makkelijke. De vervelendere variant is licht dat maar net aanwezig is: een van een paar glasvezeluplinks hier logde een Rx power low-alarm op -20,2 dBm tegen een drempel van -18,4 dBm en stapelde 46 duizend inputfouten en 42 duizend CRC-fouten op terwijl de link nominaal up bleef.
show interface transceiver detailenshow interface counters errorsvertelden dat verhaal.Het veldwerk is sowieso hetzelfde: beide eindvlakken inspecteren en reinigen, TX en RX meten, uitkijken naar een te lange run, een slechte las of een goedkope patchkabel, en de module vervangen als de niveaus laag blijven. Ik heb de exacte boosdoener bij ons nooit bewezen, dus neem het als een richting in plaats van een oordeel.
Nog iets voor de checklist aan het verre eind: een ontvanger kan uit zichzelf doodgaan zonder dat er iets mis is met de vezel.
Cisco heeft een field notice, FN-72192, over een partij QSFP-40G-LR4 - ook verkocht als QSFP-40G-LR4-S en WSP-Q40GLR4L - die de fabriek verliet met de ontvangstdetector net iets buiten zijn juiste positie. De notice slaat toe op modules met een serienummer dat met ACW begint en een datumcode tussen ACW2415xxxx en ACW2449xxxx: daarop degradeert de ontvangstkant en valt de link weg. Het platform dat genoemd wordt is de ASR 900-serie. De aanpak is vervangen bij storing, dus het is een serienummercontrole en een supportcase, niet iets dat je configureert.
Het deel dat op jouw link van toepassing is: de vroege waarschuwing is een ontvangstwaarde in de DOM-data die gestaag naar beneden zakt in plaats van van een klif te vallen. Goed argument om DOM op elke uplink te grafieken in plaats van hem pas af te lezen als er al iets kapot is.
Over het vertrouwen van de metingen: meestal wel, maar niet blindelings. Er ging een geval rond van een Huawei GPON ONT-stick in een MikroTik SFP+-slot, die een heel laag ontvangstvermogen meldde met downloads die onder 20 Mbps bleven steken op een veel snellere aansluiting, en niemand heeft ooit vastgesteld of de meting of de lijn de schuldige was. Het bleef onopgelost.
Bij een gewoon LR-paar zoals bij jou zou ik de monitoroutput op zijn woord geloven. Bij vreemde modules in een SFP+-cage is een tweede meting vanaf de andere kant de moeite waard voor je er een ritje naartoe omheen plant.