Proxmox «bridge port has no carrier»: швидке усунення неполадок кабелю, комутатора та драйвера

Що насправді означає «bridge port has no carrier»

У Proxmox мережа ВМ зазвичай розміщується на Linux‑мості, наприклад vmbr0. Цей міст має один або кілька портів (зазвичай фізичний NIC як enp3s0 або bond як bond0). Помилка з’являється, коли порт повідомляє про відсутність carrier — це спосіб Linux сказати «лінк вниз».

Carrier — це не «я можу пінгувати шлюз». Carrier — це фізичний або PHY‑рівневий сигнал лінку: інтерфейс не може домовитися про лінк з тим, що на іншому кінці. Якщо це мідний порт, зазвичай це кабель/комутатор. Якщо це оптика/DAC, то це сумісність SFP‑модуля, полярність волокна або конфігурація порту комутатора. Якщо це bond, це може бути невідповідність LACP. Якщо це драйвер — це може бути проблема з прошивкою/драйвером, енергозбереженням або NIC у дивному стані.

Попередження мосту часто є просто вісником, на якого скаржаться. Міст у порядку. Проблема у порту. Ваше завдання: з’ясувати, чому порт втратив carrier, а не чому Proxmox поскаржився.

Саме одна цитата, бо вона пасує до цієї роботи: «Сподівання — не стратегія.» — Вінс Ломбарді

Швидкий план діагностики (перший/другий/третій)

Перший: доведіть, чи це справді лінк (L1) або щось вищe

1. Перевірте стан лінку з хоста (ip link, ethtool). Якщо там написано NO-CARRIER або Link detected: no, трактуйте це як L1, поки не доведете протилежне.
2. Перевірте світлодіоди й статус порту комутатора. Мертвий світлодіод — подарунок: він дозволяє припинити сперечатися про VLAN.
3. Замініть відомий робочий елемент: кабель/DAC/SFP або підключіть до відомого працездатного порту комутатора. Робіть це рано. Це швидше, ніж бути хитрим.

Другий: якщо carrier є, шукайте проблеми L2/LACP/VLAN

1. Підтвердіть членство в мосту (bridge link). Переконайтесь, що потрібний інтерфейс підпорядкований мосту.
2. Переконайтесь, що режим VLAN відповідає комутатору (native VLAN проти tagged, trunks). Невідповідність trunk рідко показує «no carrier», але може створити враження «все мертве» і люди помилково це називають carrier‑проблемою.
3. Якщо bonding, підтвердіть стан LACP (cat /proc/net/bonding/bond0) і конфігурацію агрегації на комутаторі.

Третій: якщо лінк флапає або неправильно домовляється, підозрюйте драйвер/прошивку/EEE

1. Шукайте події flapping у journalctl і dmesg.
2. Ідентифікуйте драйвер і прошивку (ethtool -i, lspci -nnk).
3. Відключіть відомі проблемні опції для діагностики (EEE на мідних лініях, offloads у рідких випадках, ASPM). Протестуйте. Поверніть, якщо не допоможе.

Жарт №1: Найшвидший спосіб налагодити лінк — припустити, що це кабель, бо майже завжди це кабель, поки не стане тим єдиним випадком, коли це SFP, який ви «позичили» з ящика.

Цікаві факти й історичний контекст (допоможуть діагностувати швидше)

• «Виявлення carrier» старше за ваш гіпервізор: термін походить від раннього мережевого та модемного сигналінгу — Linux зберіг цю лексику, бо вона точно відображає стан PHY.
• Linux‑мости — це рідні можливості ядра, а не «річ Proxmox»: Proxmox їх конфігурує, але логіка й телеметрія — стандартні інструменти Linux (iproute2, bridge, ethtool).
• Автонегація завдавала проблеми ще з Fast Ethernet: невідповідність домовленості може спричиняти flaps, неправильну швидкість/дуплекс або «лінк є, але марний» поведінку.
• Energy Efficient Ethernet (EEE) створено для економії енергії: на деяких комбінаціях NIC+комутатор воно економить енергію, але іноді випадково рятує ваш аптайм в інший бік (не добре).
• SFP‑модулі мають «коди» й перевірки сумісності: багато вендорів нав’язують або віддають перевагу своїй оптиці; деякі NIC і комутатори вибагливі, і відмова часто виглядає як чисте «немає лінку».
• DAC‑кабелі — не просто мідні шнури: вони містять ідентифікацію та мають обмеження за довжиною/якістю; дешевий DAC може працювати на 1G, але падати на 10G.
• LACP (802.3ad) не «налаштуй і забудь»: одна сторона у статичному LAG, а інша в LACP може створювати часткову підключеність, чорні діри або переривчастий carrier залежно від реалізації.
• Передбачувані імена інтерфейсів (enpXsY): systemd/udev зменшили «eth0 рулетку», але також спричинили, що люди плутають і читають фізичні порти неправильно.
• STP і портова безпека існують, щоб запобігти петлям: комутатор може вимкнути або заблокувати порт після топологічних подій; хост бачить лінк, але трафік гине — це відрізняється від no‑carrier, але часто плутається під час інцидентів.

Практичні завдання: команди, виводи й рішення

Це ті завдання, які я виконую в продакшні, коли Proxmox повідомляє bridge port has no carrier. Кожне містить: команду, приклад реального виводу, що це означає, і яке рішення прийняти.

Завдання 1: Підтвердіть, який інтерфейс фактично «no carrier»

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp3s0           DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>
vmbr0            DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>

Значення: enp3s0 — down, і vmbr0 наслідує це. Міст без активного uplink — це паркувальний майданчик без дороги.

Рішення: Перестаньте дивитися на конфігурацію ВМ. Ви в зоні проблем хост‑NIC / комутатор / кабель.

Завдання 2: Перевірте carrier і параметри домовленості за допомогою ethtool

cr0x@server:~$ ethtool enp3s0
Settings for enp3s0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Advertised link modes:  1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: Unknown!
        Duplex: Unknown! (255)
        Auto-negotiation: on
        Link detected: no

Значення: NIC не бачить сигналів лінку. Це не проблема VLAN.

Рішення: Перевірте фізичний рівень: кабель, патч-панель, порт комутатора, трансивер.

Завдання 3: Переконайтесь, що міст налаштований так, як ви думаєте

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto enp3s0
iface enp3s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.20.30.11/24
        gateway 10.20.30.1
        bridge-ports enp3s0
        bridge-stp off
        bridge-fd 0

Значення: vmbr0 підкріплений enp3s0. Якщо enp3s0 мертвий, усе на vmbr0 мертве.

Рішення: Перевірте фізичний кабель, підключений до фізичного порту, що відповідає enp3s0. Не припускайте, що маркування правильне.

Завдання 4: Ідентифікуйте NIC і завантажений драйвер

cr0x@server:~$ lspci -nnk | sed -n '/Ethernet controller/,+4p'
03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)
        Subsystem: Intel Corporation Ethernet Server Adapter I210-T1 [8086:0001]
        Kernel driver in use: igb
        Kernel modules: igb

Значення: Тепер ви знаєте, з яким чипом маєте справу. Це важливо для відомих проблем драйвера і інструментів для прошивки.

Рішення: Якщо підозрюєте проблеми драйвера, шукайте по device ID/driver і перевіряйте версії прошивки та параметри модуля.

Завдання 5: Перевірте версії драйвера й прошивки через ethtool

cr0x@server:~$ ethtool -i enp3s0
driver: igb
version: 6.1.0-27-pve
firmware-version: 3.25, 0x80000d4b
expansion-rom-version:
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

Значення: Підтверджує версію ядра/драйвера й прошивку NIC. Якщо ви бачите flaps після оновлення ядра, тут починається кореляція.

Рішення: Якщо прошивка застаріла або невідповідна між хостами, заплануйте оновлення; наразі продовжуйте діагностику L1.

Завдання 6: Шукайте повідомлення про flapping у журналі

cr0x@server:~$ journalctl -k -b | grep -E 'enp3s0|igb|link up|link down' | tail -n 20
igb 0000:03:00.0 enp3s0: NIC Link is Down
igb 0000:03:00.0 enp3s0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
igb 0000:03:00.0 enp3s0: NIC Link is Down
igb 0000:03:00.0 enp3s0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

Значення: Лінк флапає. Зазвичай це поганий кабель, проблемний порт, маргінальна оптика/DAC або дивна взаємодія EEE — не проблема конфігурації мосту.

Рішення: Спершу замініть кабель/DAC. Якщо проблема лишається, змініть порт на комутаторі. Якщо лишається — вимкніть EEE і перевірте прошивку NIC.

Завдання 7: Перевірте стан порту в мосту і чи він реально enslaved

cr0x@server:~$ bridge link
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 master vmbr0 state disabled priority 32 cost 100

Значення: Порт є частиною vmbr0, але state disabled через відсутність carrier.

Рішення: Перестаньте налаштовувати timer‑и STP для мосту. Виправте carrier порту.

Завдання 8: Косвено перевірте симптоми на стороні комутатора через LLDP (якщо доступно)

cr0x@server:~$ lldpctl 2>/dev/null | sed -n '1,30p'
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------

Значення: Немає сусідів LLDP. Це узгоджується з відсутністю carrier, або LLDP не встановлено, або комутатор не говорить LLDP.

Рішення: Якщо очікуєте LLDP і нічого не отримуєте, це підштовхує до L1. Якщо ж отримуєте сусідів, ви швидко ідентифікуєте точний комутатор/порт.

Завдання 9: Перевірте, чи NetworkManager/systemd не конфліктує з ifupdown

cr0x@server:~$ systemctl is-active NetworkManager
inactive

Значення: Добре. Proxmox зазвичай використовує ifupdown2; не хочете, щоб NetworkManager «допомагав».

Рішення: Якщо він активний, розгляньте відключення в maintenance‑вікні, бо дві стекові мережі створюють фантомні проблеми.

Завдання 10: Акуратно опустіть/підніміть інтерфейс (контрольний поштовх)

cr0x@server:~$ ifdown enp3s0 && ifup enp3s0
ifdown: interface enp3s0 not configured

Значення: На багатьох Proxmox‑хостах фізичний інтерфейс — «manual» і контролюється мостом; ifdown може не застосовуватися. Не панікуйте.

Рішення: Перезапустіть міст обережно (carefully) або використайте ip link для перемикання, але тільки якщо маєте OOB‑доступ.

Завдання 11: Перемкніть стан лінку і перевірте, чи повернеться carrier

cr0x@server:~$ ip link set dev enp3s0 down
cr0x@server:~$ ip link set dev enp3s0 up
cr0x@server:~$ ip -br link show enp3s0
enp3s0           DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>

Значення: Якщо він залишається down без carrier, це не транзиторна програмна проблема.

Рішення: Ідіть фізично. Замініть кабель/DAC. Перевірте конфігурацію порту комутатора та його статус.

Завдання 12: Якщо це оптика/DAC — прочитайте EEPROM модуля (коли підтримується)

cr0x@server:~$ ethtool -m enp3s0 | sed -n '1,25p'
Identifier                                : 0x03 (SFP)
Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector                                 : 0x21 (Copper pigtail)
Transceiver codes                         : 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Vendor name                               : GENERIC
Vendor PN                                 : DAC-10G-1M
Vendor rev                                : A
Vendor SN                                 : ABC123456789

Значення: Ви бачите, який модуль/кабель використовується. «GENERIC» — ок, поки вендор комутатора не вирішить інакше.

Рішення: Якщо лінк вниз і модуль підозрілий (неправильний тип, дивний вендор, неправильна швидкість), замініть на відомо робочий підтримуваний optic/DAC.

Завдання 13: Перевірте стан bonding, якщо порт мосту — bond

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: down
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: fast
Aggregator selection policy (ad_select): stable

Slave Interface: enp3s0
MII Status: down
Slave queue ID: 0

Slave Interface: enp4s0
MII Status: down
Slave queue ID: 0

Значення: Bond сам по собі down, бо всі слейви down. Часто це upstream (проблема стеку комутаторів, обидва порти відключені, неправильна оптика) або спільна фізична помилка.

Рішення: Перевірте, що обидва порти комутатора увімкнені й у тому самому LACP‑групі. Також перевірте кабелювання: два «мертві» лінки часто означають, що до двох слейвів підключено один і той самий фізичний порт через помилку патчінгу.

Завдання 14: Перевірте VLAN‑субінтерфейси й vlan_filtering у мосту

cr0x@server:~$ ip -d link show vmbr0 | sed -n '1,12p'
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    bridge forward_delay 0 hello_time 2 max_age 20 ageing_time 300 stp_state 0 priority 32768 vlan_filtering 0

Значення: Міст UP і має LOWER_UP тут, тобто carrier є. (Це завдання для випадків «це не carrier, це VLAN».)

Рішення: Якщо ВМ все ще не спілкуються, переходьте до тегування VLAN, trunk‑налаштувань і правил фаєрволу — бо carrier в порядку.

Завдання 15: Підтвердіть досяжність комутатора/маршрутизатора після підняття carrier

cr0x@server:~$ ping -c 3 -I vmbr0 10.20.30.1
PING 10.20.30.1 (10.20.30.1) from 10.20.30.11 vmbr0: 56(84) bytes of data.
64 bytes from 10.20.30.1: icmp_seq=1 ttl=64 time=0.322 ms
64 bytes from 10.20.30.1: icmp_seq=2 ttl=64 time=0.289 ms
64 bytes from 10.20.30.1: icmp_seq=3 ttl=64 time=0.301 ms

--- 10.20.30.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2036ms

Значення: Базова L3‑досяжність на хості працює. Якщо ВМ все ще падають — фокусуйтеся на портах мосту, тегуванні VLAN і фаєрволі ВМ.

Рішення: Визначте, чи це лише хостова проблема (ВМ не працюють) або хост+uplink (хост теж не працює). Цей ping розділяє ці сценарії.

Жарт №2: Якщо ви налагоджуєте «no carrier» і ще не торкалися кабелю, ви фактично намагаєтесь SSH до відключеного тостера.

Кабель, комутатор, драйвер: як виглядає кожний режим відмови

1) Проблеми з кабелем/DAC/волокном (неприваблива більшість)

Відмови кабелів нудні, часті й погано задокументовані. Мідні патч‑корди ламаються від навантаження, зігнутих засувок або посереднього обтиску. DAC‑кабелі ламаються від різких вигинів і дешевого екранування. Волокно страждає від забруднення — так, пилу, який ви не бачите. У всіх цих випадках Linux повідомляє NO-CARRIER і Link detected: no.

Типові шаблони:

• Завжди down: неправильний тип кабелю, мертвий порт комутатора, мертвий порт NIC, неправильний трансивер або порт відключено адміністратором.
• Флап під навантаженням: маргінальний кабель, дивна взаємодія EEE, погане закінчення або фізичний рух (двері стояка, напруга в пучку кабелів).
• Домовляється на неправильній швидкості: невідповідність авто‑негації, погані пари або жорстко встановлена швидкість на комутаторі.

Що робити: спершу замініть фізичний елемент. Використовуйте відомо робочий кабель/DAC/оптику з сумки «works». Якщо у вас сумка не маркована — вітаю: у вас мішок таємниць.

2) Проблеми з портом комутатора (конфіг, безпека й «мовчазна допомога»)

Комутатори можуть вбивати з’єднання так, що це виглядає як фізична відмова. Деякі чесні (admin shutdown). Деякі «захисні» (port security, err‑disable, BPDU guard). А деякі просто неправильно налаштовані (швидкість/дуплекс жорстко задані).

Розрізняйте:

• Немає carrier зазвичай означає, що порт комутатора не передає сигнали лінку (вимкнений, зламався, неправильний трансивер, несумісна оптика).
• Carrier є, але трафік мертвий часто означає невідповідність VLAN, блокування STP, портову безпеку або неправильні LACP/static налаштування.

Не гадйте. Отримайте статус порту комутатора від мережевої команди або власного доступу. Якщо не можете — використайте LLDP і історію лінку на хості для виведення висновків.

3) Драйвер/прошивка/BIOS/енергополітика (випадки «вчора працювало»)

Коли хост Proxmox був стабільним місяцями, а потім почав втрачати carrier після оновлення ядра, зазвичай це:

• Регресія драйвера для конкретної моделі NIC.
• Невідповідність прошивки (особливо серверні NIC, які залежать від NVM/поведінки прошивки).
• Опції енергозбереження: ASPM, глибокі C‑states, EEE.
• Проблеми PCIe: поганий riser, маргінальний слот, налаштування BIOS.

Ключ — кореляція: чи показують логи flaps у один і той самий час кожного дня (політики живлення)? Чи почалося після оновлення pve-kernel? Чи ви перемістили кабелі і випадково це тимчасово «припинило» проблему? Ваші докази мають бути хронологічними, а не емоційними.

Три корпоративні міні-історії (як це б’є в реальному житті)

Міні-історія №1: Зневага припущенням, що спричинила outage

Середня компанія мала Proxmox‑кластер для внутрішніх сервісів: CI‑ранери, зберігання артефактів, кілька баз даних і купу «тимчасових» ВМ, що стали постійними. Після рутинного прибирання стояка один вузол почав кричати: bridge port has no carrier. Інженер on‑call припустив, що це проблема тегування VLAN, бо нещодавно ввели VLAN‑aware bridges.

Вони годину розглядали /etc/network/interfaces, перемикали vlan_filtering і перезавантажували мережу. Лінк залишався down. Припущення «нова фіча VLAN = нова проблема VLAN» було заспокійливим і хибним.

Зрештою хтось пішов до стойки. Uplink‑кабель перемкнули з NIC вузла в порт IPMI доброзичливий підрядник, який побачив два однакові RJ45 і вибрав хаос. Хост не мав carrier, бо він фактично не був підключений до потрібної мережі.

Виправлення зайняло 30 секунд: повернути кабель. Постмортем виправлення зайняло більше часу, але було важливим: вони промаркували порти, задокументували відповідність фізичного NIC імені enp*, і додали LLDP на комутаторах та хостах, щоб питання «на якому я порту?» можна було відповісти не піднімаючись до стойки.

Міні-історія №2: Оптимізація, що обернулась проти

Інший відділ хотів зменшити споживання енергії й тепло у щільному кластері. Хтось увімкнув EEE агресивно на доступних комутаторах і також підправив BIOS‑енергополітику. Вони не чіпали мережу Proxmox, тому інцидент виявився особливо заплутаним: випадкові вузли втрачали carrier на кілька секунд, потім відновлювались.

Патерн був підступний: це траплялося частіше під час низького трафіку, через що люди звинувачували «моніторинг» або «вікна бекапів», а не фізичний рівень. Логи показували цикли link down/up. Логи комутатора не були очевидно агресивними. ВМ іноді фензилися, бо corosync‑гейпсерти не любили несподіваних снів.

Справжній винуватець — комбінація: певні NIC тієї генерації не дружили з EEE‑перехідними станами на конкретній моделі комутатора. «Оптимізація» спричинила, що PHY домовлявся про енергозберігаючі стани так, що це виглядало як переривчасте відключення.

Виправили, вимкнувши EEE на конкретних портах, які використовували вузли Proxmox (не по всьому дата‑центру), і відкотили найагресивніші налаштування енергії. Споживання трохи зросло. Аптайм виріс драматично. Всі робили вигляд, що так було заплановано.

Міні-історія №3: Нудна, але правильна практика врятувала день

Фінансова команда мала звичку, що здавалася нудною: кожного разу після патчу або переміщення кабелю вони швидко запускали скрипт «link validation» на хості і додавали before/after в тикет. Він включав ip -br link, ethtool і grep‑и journalctl на події лінку.

Під час обслуговування замінили top‑of‑rack комутатор. Один Proxmox‑вузол піднявся з «no carrier» на одному члені bond. Мережевики наполягали, що порт налаштовано правильно. Серверники наполягали, що NIC у порядку. У тикеті був before‑стан, який показував обидва bond‑лінки стабільними на 10G місяцями, плюс точну EEPROM‑інформацію трансивера.

Ці докази швидко звузили проблему: новий комутатор мав іншу політику для оптики й не сприймав «GENERIC» DAC на тому порту. Вони поміняли DAC на підтримуваний. Лінк піднявся миттєво. Без довгого з’ясовування винних, без фантомних змін VLAN.

Практика не була гламурною. Вона не вимагала нового інструменту. Вона змушувала команду фіксувати «known‑good» базову лінію. Коли стався інцидент, вони не дебагали в темряві — вони порівнювали реальність із збереженим знімком реальності.

Типові помилки: симптом → корінна причина → виправлення

Це повторювані помилки, які я бачу в середовищах Proxmox — особливо після робіт у стойці, змін на комутаторах, оновлень ядра або «дрібних» рефакторів.

1) Симптом: «bridge port has no carrier» після переміщення хоста

• Корінна причина: Кабель у неправильному порту NIC (або в IPMI), невірна мапа патч‑панелі або неправильний порт комутатора.
• Виправлення: Використайте ethtool -P (permanent MAC), LLDP якщо є, і фізично перевірте шлях кабелю. Промаркуйте обидва кінці. Якщо можете — стандартизуйте: крайній лівий NIC завжди uplink A тощо.

2) Симптом: Лінк флапає кожні кілька хвилин

• Корінна причина: Маргінальний мідний патч, поганий keystone‑джек, порушення радіусу вигину DAC або взаємодія з EEE.
• Виправлення: Замініть фізичний сегмент спершу. Якщо проблема залишається, тимчасово вимкніть EEE на NIC та/або порту комутатора для діагностики. Перевірте логи на частоту flaps і кореляцію.

3) Симптом: Bond показує down, хоча один кабель підключено

• Корінна причина: Невідповідність LACP (комутатор очікує LACP, а хост в active‑backup, або навпаки), або обидва слейви підключені до одного фізичного порту через помилку патчінгу.
• Виправлення: Перевірте /proc/net/bonding/bond0 на хості і конфігурацію порт‑чанелу на комутаторі. Підтвердіть, що кожен слейв підключено до свого фізичного порту.

4) Симптом: Лінк UP, але Proxmox все одно показує попередження інтермітентно

• Корінна причина: Міст містить невикористаний інтерфейс, який down; Proxmox репортує його. Або другий порт у bond відключений.
• Виправлення: Приберіть невикористані порти з bridge/bond або підключіть їх правильно. Не тримайте «майбутні розширення» як члени в продакшн‑конфігурації, якщо вам подобаються хибні тривоги.

5) Симптом: Після оновлення ядра NIC не отримує carrier на буті

• Корінна причина: Регресія драйвера або взаємодія з прошивкою; іноді змінюється поведінка PCIe ASPM/енергозбереження.
• Виправлення: Підтвердіть версії драйвера/прошивки, перевірте dmesg на помилки і спробуйте завантажитись з попереднім ядром, якщо доступно. Заплануйте оновлення прошивки і розгляньте фіксацію на відомо‑робочому ядрі, поки не вирішите проблему.

6) Симптом: SFP‑порт показує no carrier тільки з певною оптикою

• Корінна причина: Несумісність оптики/DAC, неправильний тип (SR vs LR), неправильна швидкість (1G модуль у 10G порту) або вендор‑лок.
• Виправлення: Прочитайте модуль через ethtool -m, замініть на відомо робочий підтримуваний модуль і перевірте, що порт комутатора підтримує потрібну швидкість.

7) Симптом: «No carrier» тільки після перезавантаження, фіксується повторним перепідключенням

• Корінна причина: Знос фізичного з’єднання, защіпка не сідає, або трансивер, що ненадійно ініціалізується.
• Виправлення: Замініть патч‑кабель або трансивер. «Ресеатнув і стало гаразд» — це симптом, а не рішення.

Контрольні списки / покроковий план

Контрольний список A: Від алерту до кореневої причини за 10 хвилин

1. Підтвердіть точний інтерфейс: ip -br link. Визначте, який порт DOWN/NO-CARRIER.
2. Підтвердіть carrier через ethtool: ethtool enpXsY. Якщо Link detected: no, трактуйте як L1.
3. Перевірте членство в мосту: bridge link. Переконайтесь, що це очікуваний порт/bond.
4. Перегляньте логи на flaps проти жорсткого дауна: journalctl -k -b grep link up/down.
5. Замініть найпростіший фізичний елемент: кабель/DAC/оптика.
6. Перенесіть на інший порт комутатора: швидко усуває геть один проблемний порт або err‑disable стан.
7. Якщо bonded: перевірте /proc/net/bonding/bond0 і зіставте з конфігурацією LACP на комутаторі.
8. Якщо все ще мертво: ідентифікуйте драйвер/прошивку (ethtool -i, lspci -nnk) і розгляньте оновлення прошивки або відкат ядра.

Контрольний список B: Перш ніж чіпати продакшн‑мережу

1. Майте OOB‑доступ (IPMI/iKVM). Якщо немає — ваш «швидкий bounce» може обмежити кар’єру.
2. Зберіть стан: ip a, ip r, bridge link, ethtool і останні 200 рядків журналу ядра.
3. Знайте, як виглядає «добре»: швидкість, дуплекс, очікуваний LLDP‑сусід і який порт комутатора має світитись.
4. Робіть по одній зміні. Мережа — не ігровий автомат.

Контрольний список C: Закріплення, щоб це не будило вас знову

1. Промаркуйте порти NIC на шасі і в CMDB/тикетах. Зв’яжіть enp* з фізичними портами.
2. Увімкніть LLDP в середовищі якщо можливо (хост + комутатор). Це дешево і правдиво.
3. Стандартизуйтесь на оптиці/DAC. Змішана корзина трансиверів породжує переривчасті відмови.
4. Тримайте прошивку NIC помірно актуальною, особливо Intel/Broadcom серверні адаптери.
5. Сповіщайте про flaps, а не тільки про down. Flaps — це пожежна сигналізація; link‑down — вже пожежа.
6. Документуйте профілі портів комутатора для uplink‑ів гіпервізорів (LACP, VLAN trunking, MTU). Повторюваність краща за героїзм.

FAQ

1) Чи завжди «no carrier» означає поганий кабель?

Ні, але спочатку так і ставтесь. «No carrier» означає, що PHY не бачить лінку. Кабель/DAC/оптика і стан порту комутатора — поширені причини. Драйвери й прошивка рідше, але реальні.

2) Чи може помилка VLAN спричинити «bridge port has no carrier»?

Зазвичай ні. Помилки VLAN зазвичай тримають лінк піднятним, але ламають трафік. Якщо ethtool показує Link detected: no, VLAN — не ваша проблема.

3) Proxmox показує попередження, але хост все ще має зв’язок. Чому?

Часто тому, що міст має кілька портів і один з них down (наприклад, член bond відключений), або є невикористаний інтерфейс, що все ще приєднано. Proxmox репортує down‑порт, навіть якщо інший шлях працює.

4) Яке найшвидше доказ того, що це проблема на стороні комутатора?

Перенесіть кабель на відомо робочий порт комутатора (з тією ж профілем конфігурації). Якщо лінк підніметься одразу — початковий порт комутатора неправильний, вимкнений або зламаний.

5) Як дізнатись, чи SFP/DAC несумісний?

Прочитайте його через ethtool -m (якщо підтримується) і порівняйте з тим, що працює в інших місцях. Якщо той самий хост+порт працює з іншим модулем, а не з цим — модуль винний. Якщо модуль працює на іншому комутаторі, але не на цьому — це політика сумісності вендора.

6) Чи безпечно перезапустити інтерфейс bridge на вузлі Proxmox?

Тільки якщо маєте OOB‑доступ і розумієте, який трафік буде втрачено. Бастувати vmbr0 припиняє зв’язок для хоста і ВМ, що його використовують. Використовуйте це як контрольований крок діагностики, а не як рефлекс.

7) Мій bond в режимі LACP; чи може все одно бути «no carrier»?

Так. LACP — це L2, але carrier — L1. Якщо обидва фізичні лінки down (або оптика не розпізнана), bond піде down. Якщо один лінк down, bond може залишитися up, але з меншим пропуском і можливою зміною поведінки трафіку залежно від хешування.

8) Після заміни комутатора тільки деякі Proxmox‑хости втрачають carrier. Чому не всі?

Різні NIC і оптика поводяться по‑різному. Новий комутатор може суворіше ставитись до кодування трансиверів, може мати інші за замовчуванням швидкості/автонегацію або інші EEE‑налаштування. Гетерогенне обладнання перетворює «прості заміни» в «сюрприз‑лабораторію».

9) Чи може NIC бути «up» в ip link, але при цьому без carrier?

Так. UP означає, що інтерфейс адміністративно увімкнено. Carrier — це нижній шар, показаний як LOWER_UP. Можна мати UP без LOWER_UP.

10) Що якщо комутатор показує link up, а Linux каже no carrier?

Це рідко, але може траплятись з дефектними трансиверами, дивною домовленістю або налаштуванням порту на моніторинг/зеркалювання, що вводить в оману індикатори. Довіряйте ethtool і логам, а потім валідуйте шляхом заміни оптики/портів, щоб розв’язати суперечність.

Висновок: наступні кроки, щоб не повторювалося

«Bridge port has no carrier» — це грубе повідомлення з корисним підтекстом: перестаньте відлагоджувати оверлеї і почніть відлагоджувати андерлей. Якщо NIC не бачить лінку, ваш міст невинний, а ВМ — колатеральна шкода.

Зробіть це далі, у такому порядку:

1. Запустіть ip -br link і ethtool, щоб підтвердити справжній no‑carrier.
2. Замініть фізичний елемент (кабель/DAC/оптика). Потім спробуйте інший порт комутатора.
3. Якщо флапає, промайньте journalctl -k для хронології і розгляньте взаємодію EEE/енергії/драйвера.
4. Після відновлення carrier перевірте L2/L3 (стан bond, тегування VLAN, ping шлюзу) і тільки потім копайте в проблеми на рівні ВМ.
5. Нарешті, зробіть це буденним: маркуйте порти, стандартизуйте оптику й зберігайте before/after базові знімки у Change‑тикетах.

Перемога — це не лише усунути сьогоднішній інцидент. Це зробити так, щоб наступний «no carrier» вирішувався за п’ять хвилин і заміною кабелю, а не північним танцем з налаштуваннями мосту.