Intel X710 and a TP-Link switch: 10G DAC gives no link, port stuck in NO-CARRIER
Setting up 10G between a server and a TP-Link switch, nothing exotic. The card shows up in the system, driver loads normally, but there's no link on the port at all - no errors, no negotiation attempts.
- server: Intel X710, four 10GbE SFP+ ports, firmware 9.140.76856
- TP-Link switch, SFP+ port
- cable: OEM passive DAC SFP-10G-CU1M, one meter
- Linux, the interface shows up in the system
Port state:
ip link: <NO-CARRIER,BROADCAST,MULTICAST,UP>
ethtool: Link detected: no
Auto-negotiation: off
transceiver: internal
What I've already tried:
- brought the interface up manually:
ip link set up dev sfp1; - enabled autonegotiation:
ethtool -s sfp1 autoneg on- no change; - ran xl710-unlocker, it reports the NVM is already unlocked, so the usual vendor-lock trick isn't it.
On the switch side the port is also silent, counters at zero. Is it the cable, a limitation of the card itself, or am I missing something in the configuration?
Comments 5
There are two different locks here, and they're constantly confused. What xl710-unlocker removes is the NVM lock tied to a specific board vendor. It doesn't touch module restrictions at all: retail Intel firmware still refuses to work with SFP+ and DAC that don't have Intel coding in their EEPROM. The failure looks exactly like yours - port silent, log empty, interface in NO-CARRIER. So "NVM already unlocked" and "should accept any cable" are not the same thing.
What people actually do about it in practice:
options ixgbe allow_unsupported_sfp=1, but that's ixgbe, it has nothing to do with the X710's i40e, you don't have that knob;I'd start with a different cable unit: that's what fixed it for me, but hardware varies, check on yours. Also try a pair of plain optical modules - that will separate "the cable is disliked" from "the port is disliked".
Clarify a couple of things, otherwise it's guesswork. Is the cable rated as 10G-only or dual-rate? What does
ethtool -m sfp1show - does it read the vendor and part number, or does the port not see the module at all? And loop the same DAC between two ports of the switch itself: if the loop comes up, then the cages and cable are alive and the conversation narrows down to the card.Back with a result, though a partial one. Got another cable, this time a gigabit one - SFP-1G-DAC0.2M. It came up right away, the port went to 1000baseX, full duplex, traffic is flowing. The 10-gigabit SFP-10G-CU1M is still just as silent: NO-CARRIER and not a single message on either the card or the switch.
So the card is alive and the cage is alive, but the X710 specifically won't accept this 10G cable. For now I'm running on gigabit and looking for a DAC from the compatibility list.
There's another gotcha with DACs, unrelated to Intel: some passive SFP+ assemblies are coded for 10G only and can't fall back to 1000BASE-X. I had one such cable flat out refuse to connect a gigabit TL-SG2210MP cage with a TL-SX3008F on firmware 1.2, even though the same cable worked without issue between two 10-gigabit boxes. Only a dual-rate cable helps here, one whose spec explicitly lists both speeds, plus hard-setting 1000 Mbps and full duplex on both sides. A friend of mine has a Unifi SFP+ DAC running fine between an ER8411 and an SG2428P, so an SFP-to-SFP+ pairing isn't a death sentence by itself.
Since gigabit came up, go through speed and duplex on the switch port before you write the cable off for good. There was a case with a T1700X-16TS: the SFP+ port wouldn't link with a Synology 10G card over a branded TXC432-CU3M three-meter cable, while the same cable with the same NAS worked fine through a Netgear XS708E, and the switch was factory-reset twice. A loop of the same DAC between two SFP+ ports of the switch itself came up, meaning the cable and cages were fine.
Support suggested going step by step: confirm the cable is on the compatibility list, change speed and duplex on the SFP+ port, then set duplex to auto since it defaults to full. How it ended the author never wrote, but the steps are reasonable enough.