Aruba 2530-48G pair over a new 200 m OM4 run: port 51 Down while the J4858C modules self-test fine
We had a 200 m OM4 backbone pulled between two buildings a while back and I am trying to light it with kit we already own. Both ends are 2530s, both modules are the HPE part, and the link simply will not come up.
- 2x Aruba 2530-48G
- 2x J4858C 1000SX, port 51 on each side
- roughly 200 m of freshly installed OM4, the contractor certified it as good
- Digitus DK-2533-01 OM2 LC jumpers from the patch panel to the switch
show tech transceivers gives me this for the port:
Port 51 Down Auto 1000FDx 1000SX multiWhat I have done already:
- ran the module self test on both switches, both pass
interface 51 enableon both sides, no change, the port stays Down- swapped the two modules between the switches, same result either way round
- reseated the jumpers at the panel and at the switch
I am stuck between two theories: either both modules are duds out of the box, or the OM2 jumpers on an OM4 trunk are what is killing it. Which is more likely, and what would you test next to actually prove one of them?
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 theorising any further, shorten the link. Carry one switch over to the otther, put both J4858C in, and join them with a single patch cord - one jumper, no panels, no installed fibre. If port 51 comes Up like that, you have cleared both modules and both switch ports in one move, and what is left is on the other side of the liine: the installed fibre, the panels, the couplers, the terminations.
That is how the case I sat on went. Same 2530-48G pair, same J4858C, port 51 Down over the installed run and Up as soon as the two modules were back to back on one cord. On that evidence I would stop suspecting the optics - but be clear about what the test buys you. It isolates the segment, nothing more. Which part of the trace is bad, a panel, a splice, a connector, or simply the wrong pair patched through, stays open until somebody puts a meter or an OTDR on it.
While you are at it, I would park the OM2 theory. For 1000SX at 200 m the jumper grade is not what is stopping you, and OM3 and OM4 are mutually compatible anyway. Mixing grades is untidy and I would not build a new plant that way, but it is not the fault you are chasing.
Once the back to back test passes, go back to whoever pulled the fibre and ask for the certification results in writing, per fibre, with loss and length. Their own test declared the link good, so either something got waved through or they measured a different pair from the one you are patched into - and that is the ground to stand on when you tell them to come back and redo it.
First thing, separate two different faults that both print as Down. A port that is administratively down or misconfigured is one problem, a port that is enabled but has no light on its receiver is a completely different one. You already ran
interface 51 enableand it still reads Down, so you are in layer 1 and config is off the table.Two things that would narrow it down. What sits between the two switches physically - how many patch panels, any splice trays, any couplers someone added to make the run reach? And do you have the contractor's certification report with actual lsos figures per fibre, or just a verbal "it tested fine"?
Also confirm your duplex jumpers are not wired the same way at both panels. Straight through at both ends leaves you TX into TX, and that looks exactly like what you are describing.
Variation on the same test for when you cannot get the two switches into the same room: loop a module back on itself. Patch cord from TX to RX on the same duplex module, with an attenuator in line if it is a high power part so you do not cook the receiver. If the port comes up, the host port and the module are fine electrically and optically, and the fault is the far end, the fibre or the pairing.
Did exactly this on an MES3324F with a FIBO SFP+ that refused to link switch to switch - the loop came up immediately, which moved the search off the module and onto the span. One caveat: a self loop is useless on BiDi modules, since TX and RX are on different wavelengths. Loop a matched pair against each other instead.
For the next batch, test the modules before they go anywhere near a wall. Read EEPROM and DDM (vendor, part number, temperature, TX and RX power), measure TX power with a meter and check sensitivity with an attenuator, loop them as described above, then run a real link at the target rate with traffic and watch the error counters -
ethtool -mandiperf3cover those last two if you have a host to hand. On links you actually care about, a PRBS-31 BER run long enough to confirm below 1e-12 for NRZ is what proves the module. No single instrument validates everything.One more habit borrowed from the WISP crowd that has saved me twice: exercise every module through a warm reboot, a cold reboot and a reseat before it goes into service. Some parts link when inserted and come back dead after a power cycle - GLC-T-OEM is the classic, it only comes up after a reseat - and others report a link state that is not real. Much cheaper to find that on the bench than on a roof.