SRX1500 cluster over dark fiber: HA CONTROL poort blijft donker met SFP-LH 740-011612
Twee SRX1500 staan in aparte datacenters een paar kilometer uit elkaar, verbonden door dark fiber paren die we end-to-end zelf bezitten. Ze moeten als chassis cluster opkomen, wat betekent dat de control link over die fiber moet lopen in plaats van een patchkabel binnen één rack.
De opstelling:
- twee Juniper SRX1500, identieke hardware build
- Juniper SFP-LH 740-011612 in de HA CONTROL poort van elke node
- één toegewezen dark fiber paar voor de control link, rechtstreeks doorgepatcht
- de SFP-T koperen module die bij het chassis geleverd werd, eerder gebruikt voor een back-to-back test
Met de SFP-LH erin gebeurt er helemaal niets. Geen LED op de cage, geen link, en de cluster komt nooit tot stand:
> show chassis cluster interfaces
Control link status: Down
Control interfaces:
Index Interface Status
0 em0 DownWat ik al gedaan heb:
- de control link naar het tweede fiber paar verplaatst, geen verandering op geen van beide nodes
- de modules tussen de twee nodes omgewisseld, zelfde resultaat op beide
- de SFP-T teruggezet als sanity check, en die bleef down tot een volledige chassis restart, waarna hij meteen opkwam
Dat laatste punt stoort me meer dan de dode optic. Accepteert de HA CONTROL poort op een SRX1500 SFP-LH 740-011612 of SFP-SX 740-011613 überhaupt, of alleen de SFP-T waarmee hij geleverd wordt? En heeft iemand ooit een DWDM SFP in die poort gedraaid en werkend gekregen?
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
Voordat je de optic de schuld geeft: wat ziet de box eigenlijk in die cage? Post
show chassis hardwaremet de SFP-LH erin en controleer of er überhaupt een Xcvr-regel verschijnt voor die slot, op beide nodes. Als de module niet eens geïnventariseerd wordt, is dit geen fiber- of golflengteprobleem en gaat geen enkele hoeveelheid paren omwisselen daar iets aan veranderen.Tweede ding, tien minuten werk: stop een van die SFP-LH modules in een revenue port tegen een bekend goede peer. Linkt hij daar en blijft hij donker in de HA-cage, dan heb je de module van de poort losgekoppeld en kun je stoppen met bekvechten over het fiberplan.
Op de DWDM-helft van de vraag is er in elk geval één datapunt: iemand die Champion ONE DWDM optics draaide op de SRX1500-serie kreeg ze werkend. Bevestig voordat je die kant op gaat eerst de exacte golflengte met de optics- of DWDM-vendor, want Juniper verkoopt daar niet per se een module voor, en dan zit je op third-party optics met alles wat dat impliceert zodra je een case opent.
De HA control-poort is een ander beestje en ik zou niet aannemen dat hij zich als een revenue port gedraagt. Er is geen gepubliceerde optics-lijst voor die poort buiten de SFP-T die bij het chassis geleverd wordt, en jouw eigen test zegt dat de cage niet opnieuw gelezen wordt tijdens runtime: de koperen module kwam pas terug na een chassis restart. Dat leest alsof de poort bij het opstarten geïnventariseerd wordt en niets hem daarna nog rescant.
Als de cluster snel up moet, houd het transport dan buiten de firewall. Termineer de long haul op apparatuur die zijn brood verdient met optics, geef elke SRX een korte link op de module die hij bekend staat te accepteren, en laat het transport de golflengte bezitten. Minder elegant, veel sneller te leveren. Open sowieso een case, want dat er geen supported optics lijst voor die poort bestaat is op zich al een schriftelijk antwoord waard.
Ik sluit me aan bij het deel over de portstatus op deze boxen niet vertrouwen. Wij hebben een cluster van twee SRX380-POE-AC op Junos 21.4R3-S4.9 waar de storing de andere kant op gaat: xe-0/0/17 en xe-0/0/18 melden link UP met brandende LEDs en helemaal geen fiber erop aangesloten. Juniper SFP-SX 740-011613 als Xcvr 16-17, SFP+-10G-SR 740-021308 als Xcvr 18-19, beide nodes tonen identieke inventory in
show chassis hardware, enshow interfaces tersehoudt vol dat de interfaces up zijn.De modules opnieuw zetten veranderde exact niets. Die poorten waren bedoeld voor een reth die we uiteindelijk op ge-0/0/14-15 gebouwd hebben, dus niemand heeft er last van, en ik heb nooit antwoord gekregen of er een PR achter zit. Tussen dat en jouw donkere control-poort zou ik de optics-status op een geclusterde SRX niet als bewijs van iets fysieks behandelen.
Twee kanttekeningen voor als je verder deze weg op gaat.
Als er wel een DWDM optic in het pad terechtkomt, check dan het grid voordat je bestelt: een 50 GHz tunable tegenover vaste 100 GHz optics aan het andere eind is een bekende manier om een nacht te verliezen, en op Junos komt het kanaal van de wavelength-optie in plaats van iets dat je op de interface instelt. Raak ook niet in paniek als de box een kanaalnummer meldt dat niet overeenkomt met wat je geconfigureerd hebt terwijl het licht op de juiste golflengte zit. Dat is bij Cisco tunables vaak genoeg voorgekomen dat de CLI-uitlezing niet het ding is om te vertrouwen.
Over het algemene thema van dunne documentatie voor deze cages: zelfde platform, een SRX-SFP-1GE-T koperen module linkt vrolijk op 1 Gbps en weigert op te komen op 100 Mbps, waarbij de hardware guide de SFP-poorten 100/1000 noemt terwijl het module-datasheet 10/100/1000 zegt. Niemand kon me vertellen welke van de twee waar is.