ERS 5510-24T toont de 1000SX GBIC in system information, maar het IN USE-lampje gaat nooit branden
Twee gebouwen verbinden over een Nortel-paar dat er al langer ligt dan ik hier werk. Het plan was gewoon de bestaande huisfiber tussen de twee switches aan de praat te krijgen en klaar, maar poort 23 komt aan geen van beide kanten op.
- Twee Nortel ERS 5510-24T, software 4.0.2.02
- 1000SX SFP GBIC's, één in poort 23 op elke switch
- ruwweg 120 m gebouwfiber door de schachten, afgewerkt in het verre kastje door wie dan ook de oorspronkelijke klus deed
port 23: no link, IN USE LED dark on both switches
GBIC listed in system information on both endsWat ik geprobeerd heb:
- auto-negotiation uitgezet op poort 23 aan beide kanten
- symmetrische flow control op de poort ingesteld
- er een MLT omheen gebouwd, voor het geval de poort ergens lid van moest zijn
Niets daarvan veranderde iets. De handleiding zegt dat de GBIC in software geactiveerd moet worden, maar zegt nergens waar die instelling zit, en ik vind niets wat daarop lijkt in de menu's. Is er echt een activeringsstap die ik mis, of jaag ik helemaal het verkeerde na?
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
Het IN USE-lampje meldt niet dat er een module zit. Het blijft donker tot de poort daadwerkelijk een optische link ziet, dus het vertelt je alleen wat de poortstatus al zei - er linkt niets - en er is geen verborgen software-activeringsstap om naar te zoeken. De formulering in de handleiding stuurt iedereen dat gat in.
Twee dingen veroorzaken dit meestal, en ik ben beide al in hetzelfde gebouw tegengekomen.
Ten eerste moet de module bij het glas passen. 1000SX is een multimode-onderdeel. Als de schachten singlemode zijn, kun je configureren wat je wilt, het zal nooit linken; wat je daar nodig hebt is een LX-module, AA1419015 op dit platform.
Ten tweede, en dat is wat meestal wint bij oude huisbekabeling: transmit moet op receive terechtkomen. Een paar dat in het verre kastje achterstevoren is aangesloten, geeft precies dit symptoom - beide GBIC's zichtbaar in system information, beide kanten geconfigureerd, helemaal geen link. In het geval waar ik mee te maken had, was het omwisselen van de paren in het verre kastje de hele oplossing.
Volgorde die ik zou aanhouden: eerst uitzoeken wat er echt in de schachten ligt, dan de paren van eind tot eind nalopen op richting, dan een traject lenen waarvan je weet dat het goed is voor je de module gaat beschuldigen. Zet auto-negotiation en flow control ondertussen terug naar hun defaults, geen van beide is hier je probleem.
Voor je nog dieper in de menu's graaft: wat zit er nou echt in de schachten, multimode of singlemode? Niemand labelt dit netjes, en 120 m tussen gebouwen is precies de afstand waarop mensen daar de harde manier achter komen.
Tweede vraag: heeft iemand het verre kastje geopend en de afwerkingen gecontroleerd, of vertrouw je daar op de labels?
Een test die niets kost terwijl je op een antwoord op beide wacht: neem een kort patchkabeltje en lus één fiberpoort naar een andere op dezelfde switch. Komt die link op, dan zijn de modules en de poorten in orde en zit alles waar je naar zoekt buiten, in het traject.
Zelfde soort probleem op compleet ander materiaal: drie LANCOM GS-2326P+ switches verbonden over multimode via vloerpatchpanelen. Modules gedetecteerd, licht op de fibers, elke fiberpoort vastzittend op geen link.
Richting was uiteindelijk waar alles op wees. Licht zien op een streng zegt niets over welke kant het op gaat, en een patchpaneel in het midden van een traject is precies waar een paar wordt omgewisseld, dus loop elk paneel na en bewijs dat transmit aan de ene kant op receive aan de andere kant uitkomt.
Dan het saaie punt: beide kanten moeten hetzelfde soort optic zijn. Kortere afstand 850 nm en langere afstand 1310 nm praten niet met elkaar, een 100 Mbit-module praat niet met een gigabit-module, en multimode-optics willen multimode-glas in plaats van 9 um singlemode.
Nog iets dat wel of niet op jouw Nortels van toepassing kan zijn: sommige switches draaien bij het opstarten een modulecheck en weigeren third-party optics ronduit. Bij ons kwam er nooit een bevestigde oplossing omdat de tests op een sitebezoek wachtten, maar het lusje-testje was de stap die traject van hardware had gescheiden in een middag.
Nog een reden om geen module te vervangen op basis van een indicator alleen: bij deze platformfamilie gaat de gerapporteerde status ook de andere kant op fout.
Ik heb een stack van drie ERS 5520 met SFP-poorten 1/48 en 2/48 in een MLT. Poort 2/48 komt op met OperStatus down en een oranje vierkantje in de management-interface, terwijl de module daar gewoon met een vast groen lampje zit en verkeer de link volkomen normaal oversteekt.
Groen lampje plus frames op de draad betekent dat de optics en het glas doen wat ze moeten, en de leugen zit in de status die de stack voor die poort bijhoudt - op deze softwarelijn zijn het de members die niet de base unit zijn die het fout krijgen. Een verse base election forceren, of de stackbekabeling eruit trekken en opnieuw pluggen, is goedkoop genoeg om te proberen, en een latere image vermeldt het misschien wel als opgelost. Wat je niets oplevert, is een werkende SFP eruit trekken omdat een vierkantje in de UI oranje is.