Intel X710 и коммутатор TP-Link: 10G DAC не даёт линк, порт висит в NO-CARRIER
Собираю 10G между сервером и коммутатором TP-Link, ничего экзотического. Карта в системе видится, драйвер грузится штатно, а линка на порту нет вообще - ни ошибок, ни попыток согласования.
- сервер: Intel X710, четыре порта 10GbE SFP+, прошивка 9.140.76856
- коммутатор TP-Link, порт SFP+
- кабель: OEM пассивный DAC SFP-10G-CU1M, метр
- Linux, интерфейс в системе появляется
Состояние порта:
ip link: <NO-CARRIER,BROADCAST,MULTICAST,UP>
ethtool: Link detected: no
Auto-negotiation: off
transceiver: internalЧто уже сделал:
- поднимал интерфейс руками:
ip link set up dev sfp1; - включал автосогласование:
ethtool -s sfp1 autoneg on- без изменений; - прогнал xl710-unlocker, он отвечает, что NVM уже разблокирован, то есть привычный трюк с лочкой тут ни при чём.
На стороне коммутатора порт тоже молчит, счётчики по нулям. Дело в кабеле, в ограничениях самой карты или я упускаю что-то в настройке?
AI translation to English
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 5
Тут два разных замка, и их постоянно путают. То, что снимает xl710-unlocker, - это лочка NVM под конкретного вендора платы. Ограничений по модулям она не трогает: розничная прошивка Intel всё равно отказывается работать с SFP+ и DAC, у которых в EEPROM нет интеловской кодировки. Отказ выглядит ровно как у тебя - порт молчит, в логе пусто, интерфейс в NO-CARRIER. Так что «NVM уже разблокирован» и «должен принять любой кабель» - это не одно и то же.
Что с этим делают на практике:
options ixgbe allow_unsupported_sfp=1, но это ixgbe, к X710 с i40e оно отношения не имеет, такой ручки у тебя нет;Я бы начал с другого экземпляра кабеля: у меня так и решилось, но железо у всех разнео, проверь на своём. Заодно попробуй пару обычных оптических модулей - это разделит «не нравится кабель» и «не нравится порт».
Уточни пару вещей, иначе будет гадание. Кабель заявлен как 10G-only или как dual-rate? Что показывает
ethtool -m sfp1- вендор и партномер вычитываются или порт модуль вообще не видит? И прогони тот же DAC петлёй между двумя портами самого коммутатора: если петля поднимается, значит клетки и кабель живые и разговор сужается до карты.Вернулся с результатом, правда половинчатым. Взял ещё один кабель, на этот раз гигабитный - SFP-1G-DAC0.2M. Он поднялся сразу, порт встал в 1000baseX, full duplex, трафик ходит. Десятигигабитный SFP-10G-CU1M как молчал, так и молчит: NO-CARRIER и ни одного сообщения ни на карте, ни на коммутаторе.
То есть карта живая и клетка живая, а конкретно этот 10G-кабель X710 принимать не хочет. Пока сижжу на гигабите и ищу DAC из списка совместимости.
У DAC есть ещё одна засада, уже не интеловская: часть пассивных сборок SFP+ закодирована только под 10G и не умеет откатываться в 1000BASE-X. У меня такой кабель наотрез отказался соединять гигабитную клеку TL-SG2210MP с TL-SX3008F на прошивке 1.2, хотя между двумя десятигигабитными железками тот же кабель работал без вопросов. Помогает только dual-rate, у которого в спецификации явно указаны обе скорости, плюс жёстко выставленные 1000 Мбит/с и full duplex с обеих сторон. У знакомого при этом Unifi-шный SFP+ DAC нормально ходит между ER8411 и SG2428P, так что связка SFP и SFP+ сама по себе не приговор.
Раз уж гигабит поднялся, пройдись по скорости и дуплексу на порту коммутатора, прежде чем окончательно списывать кабель. Была история с T1700X-16TS: порт SFP+ не хотел линковаться с 10G-картой Synology по фирменному TXC432-CU3M на три метра, при этом тот же кабель с той же NAS прекрасно работал через Netgear XS708E, а свитч дважды сбрасывали к заводским настройкам. Петля из этого же DAC между двумя портами SFP+ самого коммутатора поднялась, то есть кабель и клеткки были в порядке.
Поддержка предлагала идти по шагам: убедиться, что кабель из совместимых, поменять скорость и дуплекс на порту SFP+, а потом поставить дуплекс в auto, потому что по умолчанию там full. Чем всё закончилось, автор так и не написал, но шаги вполне здравые.