Aruba 2530-48G-paar via nieuwe 200 m OM4-run: poort 51 Down terwijl de J4858C-modules de zelftest prima doorstaan
We hebben een tijdje terug een backbone van 200 m OM4 laten trekken tussen twee gebouwen en ik probeer die nu aan de praat te krijgen met apparatuur die we al hebben. Beide kanten zijn 2530's, beide modules zijn het HPE-onderdeel, en de link komt gewoon niet op.
- 2x Aruba 2530-48G
- 2x J4858C 1000SX, poort 51 aan beide kanten
- circa 200 m vers geïnstalleerde OM4, de aannemer heeft het gecertificeerd als goed
- Digitus DK-2533-01 OM2 LC-jumpers van het patchpaneel naar de switch
show tech transceivers geeft me dit voor de poort:
Port 51 Down Auto 1000FDx 1000SX multiWat ik al gedaan heb:
- de modulezelftest op beide switches gedraaid, beide slagen
interface 51 enableaan beide kanten, geen verandering, de poort blijft Down- de twee modules tussen de switches omgewisseld, zelfde resultaat in beide richtingen
- de jumpers opnieuw aangesloten bij het paneel en bij de switch
Ik zit vast tussen twee theorieën: of beide modules zijn al kapot uit de doos, of de OM2-jumpers op een OM4-trunk zijn wat de link om zeep helpt. Wat is waarschijnlijker, en wat zou je als volgende stap testen om een van de twee echt te bewijzen?
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 4
Voor je verder gaat theoretiseren: maak de link korter. Neem een switch mee naar de andere, zet er beide J4858C's in en verbind ze met één patchkabel - één jumper, geen panelen, geen aangelegde vezel. Komt poort 51 dan Up, dan heb je in één keer beide modules en beide switchpoorten vrijgepleit, en ligt wat overblijft aan de andere kant van de lijn: de aangelegde vezel, de panelen, de koppelingen, de afsluitingen.
Zo liep de zaak die ik onder handen had. Zelfde 2530-48G-paar, zelfde J4858C, poort 51 Down over de aangelegde run en Up zodra de twee modules rug aan rug op één kabel zaten. Met dat bewijs zou ik stoppen met de optiek verdenken - maar wees duidelijk over wat de test je oplevert. Hij isoleert het segment, meer niet. Welk deel van het traject slecht is, een paneel, een las, een connector, of gewoon het verkeerde paar doorgepatcht, blijft open totdat iemand er een meter of een OTDR op zet.
Nu we toch bezig zijn: ik zou de OM2-theorie laten rusten. Voor 1000SX op 200 m is de jumperklasse niet wat je tegenhoudt, en OM3 en OM4 zijn sowieso onderling compatibel. Klassen mengen is slordig en zo zou ik geen nieuw netwerk aanleggen, maar het is niet de fout waar je achteraan zit.
Zodra de rug-aan-rugtest slaagt, ga terug naar wie de vezel heeft aangelegd en vraag om de certificeringsresultaten op schrift, per vezel, met verlies en lengte. Hun eigen test verklaarde de link goed, dus of er is iets doorgewuifd, of ze hebben een ander paar gemeten dan waar jij op gepatcht zit - en dat is de basis om op te staan als je ze vraagt terug te komen en het over te doen.
Eerst dit: scheid twee verschillende problemen die allebei als Down worden weergegeven. Een poort die administratief down staat of verkeerd geconfigureerd is, is één probleem; een poort die enabled is maar geen licht op zijn ontvanger heeft, is een compleet ander verhaal. Je hebt al
interface 51 enablegedraaid en hij blijft Down tonen, dus je zit op laag 1 en configuratie valt af.Twee dingen die het zouden versmallen. Wat zit er fysiek tussen de twee switches - hoeveel patchpanelen, laseenheden, of koppelingen die iemand heeft toegevoegd om de run te laten reiken? En heb je het certificeringsrapport van de aannemer met echte verliescijfers per vezel, of alleen een mondeling "het testte goed"?
Bevestig ook dat je duplex jumpers niet aan beide panelen op dezelfde manier bedraad zijn. Rechtdoor aan beide uiteinden geeft je TX op TX, en dat lijkt precies op wat je beschrijft.
Variant op dezelfde test voor als je de twee switches niet in dezelfde ruimte krijgt: lus een module op zichzelf terug. Patchkabel van TX naar RX op dezelfde duplexmodule, met een attenuator ertussen als het een high-power onderdeel is, zodat je de ontvanger niet fikt. Komt de poort op, dan zijn de hostpoort en de module elektrisch en optisch in orde, en ligt de fout aan het verre eind, de vezel of de koppeling.
Precies dit gedaan op een MES3324F met een FIBO SFP+ die weigerde switch-naar-switch te linken - de lus kwam meteen op, waarmee de zoektocht van de module af en naar het traject toe verschoof. Eén slag om de arm: een self-loop is nutteloos op BiDi-modules, omdat TX en RX op verschillende golflengtes zitten. Lus in plaats daarvan een matchend paar tegen elkaar.
Test voor de volgende partij de modules voor ze ook maar in de buurt van een muur komen. Lees EEPROM en DDM uit (vendor, partnummer, temperatuur, TX- en RX-vermogen), meet TX-vermogen met een meter en controleer de gevoeligheid met een attenuator, lus ze zoals hierboven beschreven, en draai dan een echte link op de doelsnelheid met verkeer erop terwijl je de errortellers in de gaten houdt -
ethtool -meniperf3dekken die laatste twee als je een host bij de hand hebt. Voor links waar het echt om gaat, is een PRBS-31 BER-run lang genoeg om onder 1e-12 voor NRZ te bevestigen wat de module bewijst. Geen enkel instrument alleen bevestigt alles.Nog een gewoonte geleend van de WISP-mensen die me al twee keer gered heeft: laat elke module door een warme reboot, een koude reboot en een reseat gaan voor hij in dienst gaat. Sommige onderdelen linken bij het plaatsen en komen na een power cycle dood terug - GLC-T-OEM is het klassieke voorbeeld, hij komt pas op na een reseat - en andere melden een linkstatus die niet echt is. Een stuk goedkoper om dat op de werkbank te ontdekken dan op een dak.