Aruba S2500-24P refusing all SFP+ transceivers - 10GbE trunk to Intel X520 impossible? (ArubaOS MAS 7.4.1.12)

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

Scro

New Member
Oct 2, 2019
3
0
1
Hey all, long post but I want to be thorough because I've been banging my head against this for weeks and I'm out of ideas.

The goal: Establish a 10GbE SFP+ fiber trunk between an Aruba S2500-24P (JW668A) and an Intel X520-DA2 NIC running in a pfSense box. Short run, bench test environment, OM3 LC-LC duplex fiber.

Hardware:
  • Switch: Aruba S2500-24P-4x10G (JW668A), firmware ArubaOS MAS 7.4.1.12
  • NIC: Intel X520-DA2 (Oracle OEM), running in pfSense (FreeBSD), appears as ix0/ix1 via ixgbe driver
  • Fiber: OM3 LC-LC duplex, two different cables tested, both new
  • NIC-side optic: Genuine Intel E10GSFPSR (10GBASE-SR 850nm)
  • Switch-side optics tested: see below

The pattern I keep seeing:

Every single optic I put in the Aruba side shows the exact same behavior:

Code:
show interface transceiver
Aruba Certified: NO
And then:

Code:
show interface gigabitethernet 0/1/0
Received 0 frames, 0 octets
Transmitted 8000+ frames, XXX octets
The Aruba declares link UP at 10G full duplex, is happily transmitting frames, but receives exactly zero. On the pfSense side, ifconfig ix0 shows status: no carrier. The Intel optic's TX light is clearly reaching the Aruba RX (confirmed by shining the fiber in a dark room - one strand lit, polarity confirmed correct). Polarity was also tested - separated the duplex LC strands and swapped them on the Aruba end. Result: Link is Down on the Aruba port and zero light from either strand, confirming original polarity was correct and one direction (Intel TX → Aruba RX) was working all along. Swapping back restored the Aruba's one-directional link up state. The Aruba just isn't firing the TX laser on the switch-side optic.

Optics tried so far:
  • Juniper QFX-SFP-10GE-SR - Aruba Certified: NO, TX suppressed, same pattern
  • Aruba/HPE J9150D (genuine HPE label, OEM inside: Ligent Photonic LTF8502-BC+) - Aruba Certified: NO, TX suppressed
  • Aruba JW091A (the correct part per S2500 QuickSpecs, purchased from eBay, genuine HPE label, OEM inside: Finisar FTLX8574D3BCL-B) - Aruba Certified: NO, TX suppressed

The JW091A is literally the part number listed in the S2500 QuickSpecs ordering information. Still rejected.

Override commands - all invalid:

Code:
(config)# no transceiver-validation
% Invalid input detected at '^' marker.

(config)# allow-unsupported-transceiver
% Invalid input detected at '^' marker.

(gigabitethernet "0/1/0")# no transceiver-validation
% Invalid input detected at '^' marker.
I've read that ProVision-based switches (2920, 2930M etc.) have a hidden allow-unsupported-transceiver command available from firmware 16.02+. The S2500 is NOT a ProVision switch - it runs ArubaOS MAS (Mobility Access Switch firmware), completely different platform, and none of those commands exist (that I know of).

pfSense/X520 side is fine:

Code:
dmesg | grep ix
ix0: <Intel(R) X520 82599ES (SFI/SFP+)> - properly enumerated
ix1: same

ifconfig ix0
status: no carrier
media: Ethernet autoselect
hw.ix.unsupported_sfp=1 is set in /boot/loader.conf.local. The X520 is detecting the optic and attempting sync (local_faults incrementing in sysctl), just never gets a signal back.

One more data point - the show interface transceiver output for the JW091A:

Code:
GE0/1/0
-------
Vendor Name                                : HPE
Vendor Serial Number                       : AWN07KP
Vendor Part Number                         : FTLX8574D3BCL-B
Aruba Certified                            : NO
Cable Type                                 : 10GBASE-SR
Connector Type                             : LC
Wave Length                                : 850 nm
Genuine HPE label, correct part number, but the OEM core inside is a Finisar FTLX8574D3BCL-B and the switch still rejects it. I don't know if a different production batch of JW091A modules uses a different OEM core that would pass validation.

Current running config output is:

Code:
GE0/1/0 is administratively Up, Link is Up, Line protocol is Up
Hardware is Gigabit Ethernet, Interface is GE0/1/0, Address is 00:0b:86:ab:59:1a
Encapsulation ARPA, Loopback not set
Configured: duplex (Full), Speed (10 Gbps), FC (Off), Autoneg (Off)
Interface index: 129
MTU 1514 bytes
Link flaps: 3
Flags: Access, Trusted
Link status last changed:       0d 02:53:29 ago
Last update of counters:        0d 00:00:06 ago
Last clearing of counters:      0d 03:12:26 ago
Statistics:
    Received 0 frames, 0 octets
    0 pps, 0 bps
    0 unicast, 0 multicast, 0 broadcast
    0 runts, 0 giants, 0 throttles
    0 error octets, 0 CRC frames
    Transmitted 46981 frames, 8146136 octets
    4 pps, 6.435 Kbps
    326 unicast, 22569 multicast, 24086 broadcast
    0 throttles, 0 errors octets, 0 deferred
    0 collisions, 0 late collisions
Interface is not PoE capable
My questions:
  1. Has anyone actually gotten a 10GbE SFP+ fiber link working on an S2500 MAS with anything other than a factory-fresh genuine Aruba optic? I've seen posts elsewhere suggesting clones work on this platform but I cannot reproduce it.
  2. Is the Aruba Certified: NO flag definitively what suppresses the TX laser, or is there another explanation for zero RX frames while the port reports link up?
  3. The JW091A I received has a Finisar FTLX8574D3BCL-B core inside. Is there a known "good" batch of JW091A modules that carry a different OEM core with the correct EEPROM vendor string? Or is every JW091A in the secondary market going to have this problem?
  4. Is there any undocumented CLI command on ArubaOS MAS 7.4.1.12 that bypasses transceiver validation? I've exhausted everything I can find.
  5. Any chance this is a firmware issue and a different ArubaOS MAS version behaves differently?

For what it's worth, the switch hardware itself seems fine - port comes up at 10G full duplex, transmits frames correctly, responds to management, all RJ-45 ports work normally. This is purely a transceiver validation issue on the SFP+ ports as far as I can tell.

Appreciate any insight. Happy to run whatever CLI commands would help diagnose further.
 
Last edited: