Диагностика проблемы «линк есть на коммутаторе, но не виден на сервере»

Создана 15.09.2026
Отредактирована 18.09.2026

Введение

Одна из классических и часто встречающихся задач при эксплуатации сетевой инфраструктуры — ситуация, когда на коммутаторе порт находится в состоянии up/connected , а со стороны сервера (ОС) линк не поднимается. Внешне это выглядит как противоречие: коммутатор утверждает, что связь есть, сервер утверждает, что её нет.

В этой статье разберём пошаговый алгоритм диагностики такой проблемы на примере порта Eth1/7 коммутатора Cisco Nexus N3K-C3064PQ-10GE и сервера с оптическим подключением 10Gbase-SR. Покажем, какие команды использовать, как интерпретировать их вывод и как локализовать неисправность на конкретной стороне.

1. Постановка задачи

Исходные данные:

Клиент сообщает: со стороны ОС линка не видно.

На коммутаторе порт Eth1/7 в состоянии connected, up.

Скорость 10G, дуплекс full, тип 10Gbase-SR, VLAN 3108.

Задача: определить, на чьей стороне проблема — на коммутаторе, на сервере или в канале между ними.

2. Первичная проверка на коммутаторе

2.1. Статус порта

switch#show interface eth1/7 status -------------------------------------------------------------------------------- Port Name Status Vlan Duplex Speed Type -------------------------------------------------------------------------------- Eth1/7 server connected 3108 full 10G 10Gbase-SR

switch#show interface Eth1/7 | include up Ethernet1/7 is up admin state is up, Dedicated Interface

Вывод: порт административно и операционно поднят. Коммутатор видит линк.

2.2. Информация об оптическом модуле

switch#show interface Eth1/7 transceiver details Ethernet1/7 transceiver is present type is 10Gbase-SR name is FIBO part number is FT-S10-M8503LD revision is 1.0 serial number is G25090465 nominal bitrate is 10300 MBit/sec Link length supported for 50/125um OM2 fiber is 82 m Link length supported for 62.5/125um fiber is 26 m Link length supported for 50/125um OM3 fiber is 300 m cisco id is 3 cisco extended id number is 4 SFP Detail Diagnostics Information (internal calibration) ---------------------------------------------------------------------------- Current Alarms Warnings Measurement High Low High Low ---------------------------------------------------------------------------- Temperature 49.88 C 90.00 C -45.00 C 85.00 C -40.00 C Voltage 3.39 V 3.79 V 2.70 V 3.70 V 2.79 V Current 5.46 mA 100.00 mA 0.00 mA 90.00 mA 0.10 mA Tx Power -3.64 dBm 2.99 dBm -10.00 dBm 0.99 dBm -9.03 dBm Rx Power -3.09 dBm 0.99 dBm -15.08 dBm -1.00 dBm -13.01 dBm Transmit Fault Count = 0 ---------------------------------------------------------------------------- Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning

Что это показывает:

Параметр	Значение	Интерпретация
transceiver is present	да	Модуль вставлен в порт коммутатора
type is 10Gbase-SR	-	Совпадает с портом
Tx Power	-3.64 dBm	Мощность, которую излучает модуль коммутатора в сторону сервера
Rx Power	-3.09 dBm	Мощность, которую принимает модуль коммутатора от сервера

Важно понимать направления:

Tx Power — свет, уходящий от коммутатора к серверу.

Rx Power — свет, приходящий от сервера к коммутатору.

Оба значения в норме → оптика коммутатора исправна, и свет от сервера доходит до коммутатора.

2.3. Счётчики ошибок

switch#show interface Eth1/7 counters errors -------------------------------------------------------------------------------- Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards -------------------------------------------------------------------------------- Eth1/7 0 0 0 0 0 0 -------------------------------------------------------------------------------- Port Single-Col Multi-Col Late-Col Exces-Col Carri-Sen Runts -------------------------------------------------------------------------------- Eth1/7 0 0 0 0 0 0 -------------------------------------------------------------------------------- Port Giants SQETest-Err Deferred-Tx IntMacTx-Er IntMacRx-Er Symbol-Err -------------------------------------------------------------------------------- Eth1/7 0 -- 0 0 0 0

Все счётчики нулевые — канал чистый, без ошибок кодирования, FCS, выравнивания и т.п. Это ещё раз подтверждает: с точки зрения коммутатора физика в порядке.

2.4. MAC-таблица на порту

switch#show mac address-table interface ethernet 1/7 Legend: * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC age - seconds since last seen,+ - primary entry using vPC Peer-Link, (T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan VLAN MAC Address Type age Secure NTFY Ports ---------+-----------------+--------+---------+------+----+------------------

Пусто. Коммутатор не изучил ни одного MAC-адреса на этом порту, то есть не получил ни одного кадра от сервера.

Это важный сигнал: несмотря на наличие линка, трафик от сервера не идёт.

3. Промежуточный вывод по коммутатору

Соберём факты:

Проверка	Результат	Что означает
Порт Eth1/7	connected, up	Линк на коммутаторе есть
SFP+ модуль	present, 10Gbase-SR	Модуль исправен
Tx Power	-3.64 dBm (норма)	Коммутатор светит нормально
Rx Power	-3.09 dBm (норма)	Свет от сервера доходит
Ошибки	0	Канал чистый
MAC-таблица	пусто	Кадры от сервера не приходят

Вывод: коммутатор, его оптический модуль и канал до коммутатора — исправны. Проблема локализуется на стороне сервера.

4. Что проверить на стороне сервера

Клиенту (или серверной команде) необходимо выполнить:

Linux (bash)

ip link show [iface]
ethtool [iface]          # Link detected: yes/no, Speed, Duplex
ethtool -m [iface]       # Rx Power, Tx Power на стороне сервера
dmesg | tail -50         # ошибки драйвера
journalctl -k | grep -i [iface]
cat /sys/class/net/[iface]/carrier

* где вместо [iface] введите номер интерфейса, например команда будет выглядеть так:

ip link show enp216s0f1

Windows (powershell)

Get-NetAdapter
Get-NetAdapterAdvancedProperty -Name "[iface]"

5. Наиболее вероятные причины (в порядке убывания)

1. Неисправный или несовместимый SFP+ на стороне сервера.

Частая ситуация: серверный модуль «светит» (поэтому коммутатор видит Rx Power), но не поднимает линк логически — не выдаёт корректный сигнал Signal Detect на сетевую карту. Особенно часто встречается с non-branded модулями.

2. Повреждено обратное волокно или разъём.

Коммутатор светит, но свет не доходит до сервера → сервер не поднимает линк → не шлёт кадры.

3. Перепутаны TX/RX в патч-корде.

Для двухволоконного соединения достаточно поменять местами два волокна в LC-разъёме.

4. NIC сервера административно down.

ip link set [iface] up

5. Несовпадение скорости/автосогласования.

Серверный порт может быть принудительно настроен на 1G, тогда как коммутатор — 10G fixed.

6. Проблема с драйвером NIC.

Проверяется через dmesg / journalctl -k.

7. SFP+ вставлен не до конца в слот сервера.

6. Практический алгоритм устранения

Пошагово, от простого к сложному:

1. На сервере:

ip link set [iface] up

ethtool [iface] → проверить Link detected

ethtool -m [iface] → проверить Rx Power

dmesg | tail → посмотреть ошибки драйвера

2. Физические действия:

Поменять местами волокна TX↔RX.

Заменить патч-корд целиком.

Заменить серверный SFP+ на заведомо рабочий (лучше — оригинальный для данной NIC).

Попробовать другой порт на коммутаторе с той же конфигурацией.

3. Если линк поднялся, но трафика нет:

Проверить VLAN на сервере (access/trunk).

Проверить IP-адресацию, маршрутизацию, ARP.

Проверить firewall.

7. Схема диагностики

8. Частые ошибки при диагностике

1. Ограничиваться только проверкой статуса порта на коммутаторе.

connected/up не означает, что сервер видит линк и передаёт трафик.

2. Не смотреть MAC-таблицу.

Пустая MAC-таблица на порту — сильный сигнал о том, что трафик от удалённой стороны не приходит.

3. Путать Tx Power и Rx Power.

Tx Power — то, что модуль излучает. Rx Power — то, что он принимает. Это разные направления, и путать их при диагностике нельзя.

4. Не проверять ethtool -m на сервере.

Именно этот вывод показывает, доходит ли свет до сервера — и позволяет отличить проблему волокна от проблемы модуля.

5. Игнорировать счётчики ошибок.

Нулевые ошибки при наличии линка — признак исправного канала. Ненулевые (Symbol-Err, FCS-Err и т.п.) — признак проблемы физики.

9. Итоговые выводы

Если на коммутаторе порт up/connected, SFP+ исправен, мощности Rx/Tx в норме, ошибок нет — коммутатор и его сторона канала исправны.

Пустая MAC-таблица на порту указывает, что удалённая сторона не передаёт кадры.

В такой ситуации проблема почти наверняка на стороне сервера: SFP+, NIC, драйвер, настройки ОС или обратное волокно.

Финальную точку ставит ethtool -m на сервере — он показывает, доходит ли свет до серверного модуля, и позволяет отличить проблему волокна от проблемы модуля.

Корректная формулировка для клиента: «На нашей стороне порт в статусе up, оптический модуль исправен, мощности в норме, ошибок нет. Просим проверить вашу сторону: линк, модуль, волокно, драйвер».

Приложение: шпаргалка по командам

На коммутаторе (Cisco Nexus)

show interface Eth1/7 status show interface Eth1/7 | i up show interface Eth1/7 transceiver details show interface Eth1/7 counters errors show mac address-table interface ethernet 1/7 show logging logfile | i Eth1/7

На сервере (Linux)

ip link show [iface]
ip link set [iface]up
ethtool [iface]
ethtool -m [iface]
dmesg | tail -50
journalctl -k | grep -i [iface]
cat /sys/class/net/[iface]/carrier

На сервере (Windows)

Get-NetAdapter
Get-NetAdapterAdvancedProperty -Name "[iface]"

Примеры вывода команд: когда проблем нет и когда они есть

Разберём каждый случай на примере интерфейса ens1f0 (типичное имя для 10G NIC на сервере под Linux).

1. ip link show [iface]

✅ Проблем нет (линк поднят, всё работает)

Что важно:

LOWER_UP — есть физический линк. Это ключевой флаг.

state UP — интерфейс административно поднят.

link/ether ... — MAC-адрес есть.

❌ Проблема есть (линка нет)

Что видно:

Флаг LOWER_UP отсутствует → физического линка нет.

state UP — интерфейс административно поднят командой ip link set up

Другими словами: сервер пытается работать, но не видит линк.

Ещё вариант — интерфейс вообще опущен:

Что видно:

state DOWN — интерфейс административно опущен.

Нужно выполнить команду ip link set ens1f0 up

2. ethtool [iface]

✅ Проблем нет

$ ethtool ens1f0 Settings for ens1f0: Supported ports: [ FIBRE ] Supported link modes: 1000baseX/Full 10000baseSR/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10000baseSR/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Speed: 10000Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: external Auto-negotiation: off Supports Wake-on: d Wake-on: d Current message level: 0x00000007 (7) drv probe link Link detected: yes ← ЛИНК ЕСТЬ

Что важно:

Speed: 10000Mb/s — скорость согласована.

Duplex: Full — полный дуплекс.

Link detected: yes — ключевой признак, что физика в порядке.

❌ Проблема есть (линка нет)

$ ethtool ens1f0 Settings for ens1f0: Supported ports: [ FIBRE ] Supported link modes: 1000baseX/Full 10000baseSR/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Advertised link modes: 10000baseSR/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Speed: Unknown! Duplex: Unknown! (255) Port: FIBRE PHYAD: 0 Transceiver: external Auto-negotiation: off Supports Wake-on: d Wake-on: d Current message level: 0x00000007 (7) drv probe link Link detected: no ← ЛИНКА НЕТ

Что видно:

Speed: Unknown! — скорость не определена, потому что линка нет.

Duplex: Unknown! (255) — то же самое.

Link detected: no — физического линка нет.

Именно эту картину вы, скорее всего, увидите у клиента в вашем кейсе.

3. ethtool -m [iface]

Эта команда читает EEPROM оптического модуля на стороне сервера. Требует прав root и поддержки драйвером.

✅ Проблем нет

$ ethtool -m ens1f0 Identifier : 0x03 (SFP) Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID) Connector : 0x07 (LC) Transceiver codes : 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Transceiver type : 10G Ethernet: 10G Base-SR Encoding : 0x06 (64B/66B) BR, Nominal : 10300MBd Rate identifier : 0x00 Length (SMF,km) : 0 Length (OM3 50um) : 300m Length (OM2 50um) : 82m Length (OM1 62.5um) : 26m Vendor name : FIBO Vendor OUI : 00:00:00 Vendor PN : FT-S10-M8503LD Vendor SN : C20090488 Laser wavelength : 850nm ... Diagnostics : yes Temperature : 48.50 C Voltage : 3.35 V Optical output power : 0.45 mW (-3.47 dBm) ← Tx Power на сервере Receiver signal average optical power : 0.42 mW (-3.77 dBm) ← Rx Power на сервере ... Laser output power : 0.45 mW / -3.47 dBm Receiver signal average optical power : 0.42 mW / -3.77 dBm

Что важно:

Diagnostics: yes — модуль поддерживает DOM.

Optical output power (Tx) — мощность, которую излучает серверный модуль.

Receiver signal average optical power (Rx) — мощность, которую принимает серверный модуль от коммутатора.

Оба значения в норме → свет идёт в обе стороны.

❌ Проблема есть (свет до сервера не доходит)

$ ethtool -m ens1f0 Identifier : 0x03 (SFP) Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID) Connector : 0x07 (LC) Transceiver codes : 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Transceiver type : 10G Ethernet: 10G Base-SR Encoding : 0x06 (64B/66B) BR, Nominal : 10300MBd ... Vendor name : FIBO Vendor PN : FT-S10-M8503LD Vendor SN : C20090488 ... Diagnostics : yes Temperature : 48.50 C Voltage : 3.35 V Optical output power : 0.45 mW (-3.47 dBm) ← Сервер светит нормально Receiver signal average optical power : 0.0012 mW (-29.21 dBm) ← Свет от коммутатора почти не доходит! ...

Что видно:

Optical output power в норме → серверный модуль излучает нормально.

Receiver signal average optical power аномально низкий (например, -29 dBm вместо ожидаемых -3…-9 dBm) → свет от коммутатора до сервера не доходит.

Причина: обратное волокно повреждено или разъём/коннектор загрязнён, либо приёмная часть серверного модуля неисправна.

Другой вариант — модуль не поддерживает DOM:

$ ethtool -m ens1f0 Cannot get module EEPROM information: Operation not supported

Или модуль вообще не читается:

$ ethtool -m ens1f0 Cannot get module EEPROM information: No such device

Это тоже косвенный признак проблемы — несовместимый или неисправный модуль.

4. dmesg | tail -50

✅ Проблем нет

$ dmesg | tail -50
[   12.345678] ixgbe 0000:03:00.0 ens1f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[   12.345679] IPv6: ADDRCONF(NETDEV_CHANGE): ens1f0: link becomes ready
...

Что важно:

Сообщение NIC Link is Up 10 Gbps — драйвер увидел линк.

link becomes ready — интерфейс готов к работе.

Никаких ошибок.

❌ Проблема есть (линка нет)

$ dmesg | tail -50
[   10.123456] ixgbe 0000:03:00.0: Intel(R) 10 Gigabit Network Connection
[   10.123457] ixgbe 0000:03:00.0 ens1f0: registered PHC device 0
[   10.234567] ixgbe 0000:03:00.0 ens1f0: NIC Link is Down
[   15.345678] ixgbe 0000:03:00.0 ens1f0: NIC Link is Down
[   20.456789] ixgbe 0000:03:00.0 ens1f0: NIC Link is Down
...

Что видно:

Многократные NIC Link is Down — линк не поднимается.

Сообщения повторяются с интервалом → драйвер периодически пытается поднять линк и не может.

Другие варианты ошибок:

[   10.123456] ixgbe 0000:03:00.0: Failed to read Rx power
[   10.123457] ixgbe 0000:03:00.0: Unsupported SFP+ module detected
[   10.123458] ixgbe 0000:03:00.0: SFP+ module is not compatible with this adapter

Что видно:

Failed to read Rx power — модуль не отдаёт диагностику, вероятно неисправен.

Unsupported SFP+ module или not compatible — прямая причина: серверный SFP+ несовместим с NIC. Это классическая ситуация с non-branded модулями.

5. journalctl -k | grep -i [iface]

✅ Проблем нет

$ journalctl -k | grep -i ens1f0 Sep 15 10:00:01 server kernel: ixgbe 0000:03:00.0 ens1f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX Sep 15 10:00:01 server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): ens1f0: link becomes ready Sep 15 10:00:05 server kernel: ens1f0: 10 Gbps speed detected

Что важно: те же сообщения, что и в dmesg, но с временными метками — удобно сопоставлять с моментом подключения.

❌ Проблема есть

$ journalctl -k | grep -i ens1f0 Sep 15 10:00:01 server kernel: ixgbe 0000:03:00.0 ens1f0: NIC Link is Down Sep 15 10:00:03 server kernel: ixgbe 0000:03:00.0 ens1f0: NIC Link is Down Sep 15 10:00:05 server kernel: ixgbe 0000:03:00.0 ens1f0: NIC Link is Down Sep 15 10:00:07 server kernel: ixgbe 0000:03:00.0 ens1f0: NIC Link is Down ...

Что видно: периодические попытки поднять линк, которые заканчиваются неудачей. Причём записи идут с интервалом в 2 секунды — драйвер циклически пытается согласовать линк и не может.

Особенно полезный случай — несовместимый модуль:

Sep 15 10:00:01 server kernel: ixgbe 0000:03:00.0: Unsupported SFP+ module detected Sep 15 10:00:01 server kernel: ixgbe 0000:03:00.0: The installed SFP+ module is not supported by this adapter Sep 15 10:00:01 server kernel: ixgbe 0000:03:00.0 ens1f0: NIC Link is Down

Что видно: драйвер прямо говорит, что модуль не поддерживается. Это ответ на вопрос «почему нет линка».

6. cat /sys/class/net/<iface>/carrier

Это самый простой и быстрый способ проверить наличие линка — читается из sysfs.

✅ Проблем нет

$ cat /sys/class/net/ens1f0/carrier 1

Что означает: 1 — линк есть (carrier detected).

❌ Проблема есть

$ cat /sys/class/net/ens1f0/carrier 0

Что означает: 0 — линка нет.

Если интерфейс административно опущен:

$ cat /sys/class/net/ens1f0/carrier cat: /sys/class/net/ens1f0/carrier: Invalid argument

Что означает: интерфейс в состоянии DOWN, сначала нужно ip link set ens1f0 up

Сводная таблица: сравнение «норма» vs «проблема»

Команда	✅ Норма	❌ Проблема
ip link show	<...UP,LOWER_UP> state UP	<...UP> state UP без LOWER_UP, или state DOWN
ethtool	Speed: 10000Mb/s, Duplex: Full, Link detected: yes	Speed: Unknown!, Duplex: Unknown!, Link detected: no
ethtool -m	Tx и Rx Power в норме (-3…-9 dBm для SR)	Rx Power = -inf / -29 dBm, либо Operation not supported
dmesg	NIC Link is Up 10 Gbps	Повторяющиеся NIC Link is Down, Unsupported SFP+ module
journalctl -k	NIC Link is Up с меткой времени	Циклические NIC Link is Down, not supported
cat .../carrier	1	0 (или ошибка, если интерфейс down)

Практический сценарий для этого кейса

Если у клиента ситуация, как в вашей задаче (на коммутаторе линк есть, на сервере нет), вывод команд, скорее всего, будет таким:

Диагноз: серверный модуль излучает (Tx в норме), но не принимает свет от коммутатора (Rx аномально низкий). Причина — обратное волокно/разъём повреждены либо приёмная часть серверного SFP+ неисправна. Решение — заменить патч-корд, поменять местами волокна TX↔RX, заменить серверный модуль.

Итог

ip link show → смотреть флаг LOWER_UP и state

ethtool → смотреть Link detected, Speed, Duplex

ethtool -m → смотреть Optical output power (Tx) и Receiver signal average optical power (Rx). Это ключ к различению проблемы волокна и проблемы модуля.

dmesg / journalctl -k → искать NIC Link is Up/Down, Unsupported SFP+ module

cat .../carrier → быстрый ответ 0 или 1

Совокупность этих команд даёт полную картину и позволяет точно локализовать проблему — на стороне коммутатора, сервера или канала между ними.