SRX1500 cluster over dark fiber: HA CONTROL port stays dark with SFP-LH 740-011612
Two SRX1500 sit in separate data centres a few kilometres apart, joined by dark fiber pairs we own end to end. They have to come up as a chassis cluster, which means the control link has to cross that fiber instead of a patch cord inside one rack.
The setup:
- two Juniper SRX1500, identical hardware build
- Juniper SFP-LH 740-011612 in the HA CONTROL port of each node
- one dedicated dark fiber pair for the control link, patched straight through
- the SFP-T copper module that shipped with the chassis, ussed earlier for a back to back test
With the SFP-LH in place there is nothing at all. No LED on the cage, no link, and the cluster never forms:
> show chassis cluster interfaces
Control link status: Down
Control interfaces:
Index Interface Status
0 em0 DownWhat I have already done:
- moved the control link onto the second fiber pair, no change on either node
- swapped the modules between the two nodes, same result on both
- put the SFP-T back as a sanity check, and it stayed down until a full chassis restart, after which it came straight up
That last point bothers me more than the dead optic. Does the HA CONTROL port on an SRX1500 accept SFP-LH 740-011612 or SFP-SX 740-011613 at all, or only the SFP-T it ships with? And has anyone run a DWDM SFP in that port and had it work?
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
Before blaming the optic, what does the box actually see in that cage? Post
show chassis hardwarewith the SFP-LH inserted and check whether an Xcvr line appears for the slot at all, on both nodes. If the module is not even inventoried, this is not a fiber or a wavelength problem and no amount of pair swapping is going to change it.Second thing, ten minutes of work: put one of those SFP-LH modules into a revenue port against a known good peer. If it links there and stays dark in the HA cage, you have separated the module from the port and can stop arguing about the fiber plant.
On the DWDM half of the question there is at least one data point: someone running Champion ONE DWDM optics on the SRX1500 series had them working. Before going that way, confirm the exact wavelength with the optics or DWDM vendor first, because Juniper does not necessarily sell a module for it, and then you are on third party optics with everything that implies the moment you oen a case.
The HA control port is a different animal and I would not assume it behaves like a revenue port. There is no published optics list for it beyond the SFP-T that ships with the chassis, and your own test says the cage is not re-read at runtime: the copper module only came back after a chassis restart. That reads like the port is inventoried at boot and nothing rescans it afterwards.
If the cluster has to be up soon, keep the transport outside the firewall. Terminate the long haul on gear that does optics for a living, hand each SRX a short link on the module it is known to accept, and let the transport own the wavelength. Less elegant, much faster to deliver. Raise a case regardless, because the supported optics lit for that port not existing is itself worth a written answer.
Seconding the part about not trusting the port state on these boxes. We have a cluster of two SRX380-POE-AC on Junos 21.4R3-S4.9 where the failure runs the other way: xe-0/0/17 and xe-0/0/18 report link UP with lit LEDs and no fiber connected to them at all. Juniper SFP-SX 740-011613 as Xcvr 16-17, SFP+-10G-SR 740-021308 as Xcvr 18-19, both nodes showing identical inventory in
show chassis hardware, andshow interfaces terseinsisting the interfaces are up.Reseating the modules changed exactly nothing. Those ports were meant for a reth that we ended up building on ge-0/0/14-15, so nobody is hurt by it, and I never got an answer on whether there is a PR behind it. Between that and your dark control port, I would not treat the optics state on a clustered SRX as evidence of anything physical.
Two side notes for when you get further down this road.
If a DWDM optic does end up in the path, check the grid before ordering: a 50 GHz tunable against fixed 100 GHz optics on the far end is a well known way to lose a night, and on Junos the channel comes from the wavelength option rather than anything you set on the interface. Also do not panic if the box reports a channel number that disagrees with what you configured while the light is on the right wavelength. That has shown up on Cisco tunables often enough that the CLI readout is not the thing to trust.
On the general theme of thin documentation for these cages: same platform, an SRX-SFP-1GE-T copper module links happily at 1 Gbps and refuses to come up at 100 Mbps, with the hardware guide calling the SFP ports 100/1000 while the module datasheet says 10/100/1000. Nobody could tell me which of the two is true either.