Ethernet застряг на 100 Мбіт/с: міф про кабель і реальне вирішення

Було корисно?

Все починається з «швидкого» інциденту: «Новий комп’ютер повільний.» Ви глядаєте на LED індикатори лінку і бачите це — ваш гордий порт 1 Gbps домовляється на 100 Mbps, наче це 2003 рік і Napster повертається.

Хтось одразу каже «замініть кабель». Іноді вони праві. Частіше — ні. Справжнє виправлення зазвичай знаходиться вище, збоку або заховано в хащах autonegotiation, де помилки йдуть в могилу.

Що насправді означає 100 Мбіт/с (і чого це не означає)

Лінк 100 Мбіт/с на NIC і комутаторі, здатних до гігабіту, рідко є «проблемою продуктивності». Це — результат узгодження. Два PHY (фізичні трансивери) спробували домовитися про найвищий спільний знаменник і зупинилися на 100BASE-TX. Зазвичай це відбувається з однієї з чотирьох причин:

  1. Ефективно працюють лише дві пари (100BASE-TX використовує дві пари; 1000BASE-T потребує всіх чотирьох).
  2. Autonegotiation зламаний або неузгоджений (на одному кінці примусова швидкість/дуплекс; посередній пристрій поводиться дивно).
  3. Конфіг портів комутатора навмисно обмежена (політика безпеки, сумісність зі старими пристроями, міфи щодо економії енергії).
  4. PHY незадоволений (помилки, EEE-особливості, драйвер/прошивка, маргінальний SNR або пошкоджений порт).

«Просто поміняти кабель» заспокоює, бо це виглядає механічно і без вини. Але якщо ви міняєте патчкорд на тракті, що включає патч-панель, keystone-розетку, вбудований проміжок, док на столі і напівмертвий порт комутатора — ви проводите науку за відчуттями.

Жарт №1: Заміна випадкових кабелів — це як перезавантаження принтерів: іноді допомагає, і ніхто не знає чому, включно з принтером.

Також не плутайте швидкість лінку з пропускною здатністю. Ви можете мати лінк 1 Gbps і все одно отримувати 80 Мбіт/с через затори, CPU, невідповідний MTU, сховище або фаєрвол, що робить глибоку інспекцію пакетів із лінощами. Цей матеріал про протилежне: сам лінк застряг на 100 Мбіт/с.

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

Перший: підтвердьте, що і де домовляється

  • На хості: підтвердіть фактичну узгоджену швидкість/дуплекс і чи увімкнено autoneg.
  • На комутаторі: підтвердіть, що комутатор думає про порт і чи він примусовий.
  • На шляху: ідентифікуйте все між NIC і комутатором (док, інлайн-роз’єднювач, настінна розетка, патч-панель).

Другий: швидко ізолюйте фізичний шлях

  • Перенесіть хост до комутатора відомим коротким справним кабелем. Якщо там домовляється 1G, проблема в структурованій кабельній системі або проміжному обладнанні.
  • Поміняйте порт на комутаторі. Якщо проблема слідує за портом — це конфігурація або апаратна проблема порту. Якщо проблема слідує за кабелем/шляхом — ви щось дізналися.

Третій: шукайте вбивць узгодження

  • Несумісність примусової швидкості/дуплексу (класика: комутатор примусово 100/full, хост autoneg).
  • EEE (Energy Efficient Ethernet) взаємодії в дешевих комутаторах, доках і деяких NIC.
  • Регіграції драйверів/прошивки, особливо навколо USB NIC і док-станцій.

Якщо ви проведете ці три проходи, зазвичай можна припинити здогадки за 10–15 хвилин і перейти до виправлення.

Міф про кабель: чому він популярний і чому це неповна відповідь

Кабелі ламаються. Але «кабель» рідко буває лише кабелем. В офісах і дата-центрах «кабель» — це ланцюг: патчкорд → keystone-джек → внутрішній проліт → патч-панель → патчкорд → комутатор. Будь-який із цих вузлів може втратити пару, ввести перехресні наводки або бути погано зімкненим так, що гігабіт падає, а 100 Мбіт/с обережно повзе далі.

Ось незручна правда: 100BASE-TX прощає більше. Він може працювати на двох робочих парах з терпимим шумом. 1000BASE-T не прощає. Він потребує всіх чотирьох пар і використовує складніше кодування (PAM-5 з echo cancellation). Це означає, що одна маргінальна клема може бути невидимою на 100, але катастрофічною на 1000.

Тому так, ви можете «виправити» це, замінивши патчкорд — бо ви випадково прибрали єдиний поганий сегмент. Але якщо справжня проблема в погано обжатій настінній розетці, ви просто кинули кубик і назвали це інженерією.

Справжні причини: autoneg, пари, помилки PHY і дивні поведінки комутаторів

1) Одна (або дві) погані пари в мідному тракті

Гігабіт потребує всіх чотирьох пар: (1,2), (3,6), (4,5), (7,8). 100 Мбіт/с використовує лише (1,2) та (3,6). Якщо пара (4,5) або (7,8) відкрита, замкнена, поміняна місцями або ледь контактує — autoneg часто відкотиться до 100.

Поширені причини:

  • Keystone-джек обжатий з поганим контактом на одній парі.
  • Патч-панель, обжаття якої робив хтось, хто поспішав на обід.
  • Старий кабель з перегинами, скріпленнями або надто малим радіусом вигину (так, люди підганяють кабель степлером; так, це так само погано, як звучить).
  • Інлайн-роз’єднювачі та дешеві подовжувачі, які фактично не відповідають Cat5e/6.

2) Несумісність autonegotiation і примусові налаштування

Autonegotiation на практиці не опційний для гігабіту. Стандарт 1000BASE-T очікує autoneg для встановлення master/slave таймінгів і можливостей. Якщо одна сторона примусова, а інша — auto, можна опинитися на 100 Mbps, у half-duplex або з флапаючим лінком.

Класичний корпоративний режим відмови: хтось колись примусово встановив 100/full на комутаторі «для стабільності» і забув. Порт стає пасткою для будь-якого сучасного кінцевого пристрою, що очікує гігабіт.

3) Дуплекс-несумісність (ще існує, але хитріша)

Дуплекс-несумісність тепер менш поширена, бо auto/auto зазвичай працює. Але вона все ще трапляється з примусовими конфігураціями, старим обладнанням або проміжними пристроями. Симптоми можуть виглядати як «лінк піднятий, але все працює погано»: багато пізніх колізій, погана TCP-продуктивність, випадкові ретрансляції.

4) Energy Efficient Ethernet (EEE) і енергозберігаючі «фічі»

EEE (802.3az) може працювати нормально. Але воно також може бути джерелом проблем узгодження на деяких чіпсетах і особливо на доках/USB NIC. Якщо ви бачите флапи лінку або впертий 100 Mbps на інакше доброму тракті — тестування з відключеним EEE варте 60 секунд вашого часу.

5) Доки, USB NIC і «корисні» адаптери

USB Ethernet адаптери і док-станції — це продуктивні чудеса аж до того моменту, коли вони ними не є. Багато з них мають маргінальні PHY, дивну прошивку і дешеві магнітні компоненти. Вони також додають більше конекторів і більше точок відмови.

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

6) Аппаратне деградування або забруднення порту комутатора

Порти комутаторів можуть псуватися. Так само можуть псуватися RJ-45 штекери на часто рухомих патчкордах. У запилених умовах порти накопичують сміття, яке невидиме, поки ви не підсвітите і не зрозумієте, що контакти виглядають так, ніби пройшли маленьку війну.

7) Регресії драйверів/прошивки

Особливо на серверах із певними NIC, оновлення прошивки може змінити поведінку autoneg або значення EEE за замовчуванням. В підприємстві це часто з’являється після вікна обслуговування, де «нічого мережного не змінювалося», хоча все змінилося.

8) Нудна, але реальна причина: політика і навмисне обмеження швидкості

Деякі організації навмисно встановлюють певні портові доступи на 100 Мбіт/с, щоб зменшити вплив широкомовлення, відлякати несанкціоновані комутатори або сумістити старі пристрої. Якщо ви діагностуєте, завжди враховуйте, що «зламано» може бути фактично «налаштовано».

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

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

Завдання 1: Підтвердьте узгоджену швидкість/дуплекс в Linux (ethtool)

cr0x@server:~$ sudo 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
	                        100baseT/Full
	                        10baseT/Full
	Advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Що це означає: NIC підтримує гігабіт, але наразі на 100/full. Autoneg увімкнено. Це вказує не на «примусові 100 на хості», а на проблему в кабелі/шляху, конфігурації комутатора або на тому, що віддалений кінець рекламує лише 100.

Рішення: Перевірте стан порту комутатора і лічильники наступним кроком. Якщо комутатор також повідомляє 100, ви маєте результат узгодження. Якщо комутатор показує 1000, а хост — 100, у вас проблема на боці драйвера/прошивки або на хості.

Завдання 2: Швидко показати стан лінку (ip)

cr0x@server:~$ ip -br link show enp3s0
enp3s0             UP             3c:ec:ef:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP>

Що це означає: Інтерфейс адміністративно увімкнено і має carrier. Це не покаже швидкість, але скаже, що ви не діагностуєте відсутній лінк.

Рішення: Якщо carrier відсутній (без LOWER_UP), зупиніться і перевірте фізичне підключення, порт комутатора в err-disable або політики VLAN/безпеки перед тим, як чіпати налаштування швидкості.

Завдання 3: Перевірте kernel-повідомлення на флапи лінку (dmesg)

cr0x@server:~$ sudo dmesg -T | tail -n 12
[Mon Feb  5 10:12:03 2026] e1000e 0000:03:00.0 enp3s0: Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
[Mon Feb  5 10:14:17 2026] e1000e 0000:03:00.0 enp3s0: Link is Down
[Mon Feb  5 10:14:20 2026] e1000e 0000:03:00.0 enp3s0: Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx

Що це означає: Лінк флапає. Це кричущий симптом маргінального фізичного рівня (кабель/обжаття/порт) або дивних енергозберігаючих режимів/EEE.

Рішення: Поміняйте порт комутатора і обійдіть док/адаптер. Якщо на відомому короткому кабелі стабілізується 1G — ви ізолювали структуровану кабельну систему або проміжний пристрій.

Завдання 4: Шукайте CRC, frame і alignment помилки (ethtool -S)

cr0x@server:~$ sudo ethtool -S enp3s0 | egrep -i 'crc|align|error|drop' | head
     rx_crc_errors: 184
     rx_frame_errors: 0
     rx_errors: 184
     rx_dropped: 3
     tx_errors: 0

Що це означає: CRC помилки вказують на пошкоджені кадри на рівні 2 — часто фізичний рівень (поганий кабель/пари, EMI, поганий порт) або дуплекс-несумісність.

Рішення: Якщо CRC піднімається постійно навіть при легкому навантаженні — спочатку розглядайте фізичний рівень: кабель/шлях/порт. Якщо CRC стрибає лише під навантаженням і дуплекс неузгоджений — виправте дуплекс/autoneg.

Завдання 5: Підтвердьте, що NIC рекламує (ethtool advertise)

cr0x@server:~$ sudo ethtool enp3s0 | egrep -A2 'Advertised link modes|Advertised auto'
	Advertised link modes:  1000baseT/Full
	                        100baseT/Full
	                        10baseT/Full
	Advertised auto-negotiation: Yes

Що це означає: Хост пропонує 1000/full. Отже, якщо ви застрягли на 100 — віддалений кінець може не пропонувати 1000 (конфіг або обмеження), або фізичний рівень не дозволяє трейнінгу гігабіту.

Рішення: Залогіньтеся в комутатор і перевірте, чи порт встановлено на auto і чи він підтримує гігабіт.

Завдання 6: Примусити повторне узгодження без ребуту (перебити інтерфейс)

cr0x@server:~$ sudo ip link set dev enp3s0 down
cr0x@server:~$ sudo ip link set dev enp3s0 up
cr0x@server:~$ sudo ethtool enp3s0 | egrep 'Speed|Duplex|Auto-negotiation|Link detected'
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Що це означає: Повторне узгодження пройшло успішно. Таке може статися, коли віддалений кінець був у дивному стані або док/NIC мав тимчасову проблему.

Рішення: Якщо це виправляє проблему регулярно, у вас все одно залишається корінна причина — часто EEE, прошивка або маргінальне кабелювання. Не святкуйте перемогу, поки це не тримається під час простою, навантаження і кількох подій лінку.

Завдання 7: Тимчасово відключити EEE для тесту (ethtool –set-eee)

cr0x@server:~$ sudo ethtool --show-eee enp3s0
EEE Settings for enp3s0:
	EEE status: active
	Tx LPI: enabled
	Rx LPI: enabled
	Supported EEE link modes: 1000baseT/Full
	Advertised EEE link modes: 1000baseT/Full
	Link partner advertised EEE link modes: 1000baseT/Full

cr0x@server:~$ sudo ethtool --set-eee enp3s0 eee off
cr0x@server:~$ sudo ethtool --show-eee enp3s0 | egrep 'EEE status|Tx LPI|Rx LPI'
	EEE status: disabled
	Tx LPI: disabled
	Rx LPI: disabled

Що це означає: EEE тепер вимкнено на стороні хоста. Якщо лінк тепер правильно узгоджується і перестає флапати — ви знайли проблему сумісності.

Рішення: Якщо EEE-off виправляє — розгляньте вимкнення EEE на порті комутатора також (або оновлення прошивки дока/NIC). Потім вирішіть, чи варті енергозбереження постійних інцидентів. Зазвичай: ні.

Завдання 8: Підтвердьте модель/драйвер PCIe NIC (lspci)

cr0x@server:~$ lspci -nnk | grep -A3 -i ethernet
03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I219-LM [8086:15d7] (rev 31)
	Subsystem: Dell Device [1028:07a1]
	Kernel driver in use: e1000e
	Kernel modules: e1000e

Що це означає: Ви знаєте чіпсет і драйвер. Це важливо при кореляції з відомими проблемами узгодження або вимогами прошивки.

Рішення: Якщо це USB NIC або менш відомий чіпсет і ви бачите повторювані 100 Mbps узгодження — протестуйте іншим адаптером. Життя коротке.

Завдання 9: Перевірте LLDP сусіда з боку хоста

cr0x@server:~$ sudo lldpctl enp3s0
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    enp3s0, via: LLDP, RID: 1, Time: 0 day, 00:00:25
  Chassis:
    ChassisID:    mac 00:11:22:33:44:55
    SysName:      access-sw-7f
  Port:
    PortID:       ifname Gi1/0/17
    PortDescr:    GigabitEthernet1/0/17

Що це означає: Ви ідентифікували точний комутатор і порт без гри «який шафа?».

Рішення: Тепер ви можете перевірити конфіг і лічильники конкретного інтерфейсу на комутаторі. Якщо LLDP відсутній — можливо ви підключені через «тупий» проміжний пристрій (mini-switch, док, медіаконвертер), який не говорить LLDP.

Завдання 10: На комутаторі перевірте стан інтерфейсу і узгодження (у стилі Cisco)

cr0x@server:~$ ssh netops@access-sw-7f "show interfaces gi1/0/17 status"
Port      Name               Status       Vlan       Duplex  Speed Type
Gi1/0/17  user-desk-117      connected    20         a-full  a-100  10/100/1000BaseTX

Що це означає: Комутатор погоджується: автонег дуплекс повний, автонег швидкість, але впав на 100. Порт підтримує гігабіт, отже обмеження — в узгодженні/фізиці, а не в здатності порту.

Рішення: Перевірте лічильники помилок і підтвердьте, що порт не примусово обмежений.

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

cr0x@server:~$ ssh netops@access-sw-7f "show interfaces gi1/0/17 counters errors"
Port        Align-Err  FCS-Err  Xmit-Err  Rcv-Err  UnderSize  OutDiscards
Gi1/0/17           0      219         0        0          0            0

Що це означає: FCS помилки збігаються з CRC з боку хоста. Фізичний рівень тепер — головний підозрюваний.

Рішення: Перенесіть кінцеву точку на відомий справний кабель/порт; якщо помилки зупиняються — шлях кабелю поганий. Якщо помилки тримаються на різних кабелях — підозрюйте апаратний порт NIC або порт комутатора.

Завдання 12: Перевірте, чи порт комутатора примусово встановлений на 100 (у стилі Cisco running-config)

cr0x@server:~$ ssh netops@access-sw-7f "show running-config interface gi1/0/17"
Building configuration...

Current configuration : 162 bytes
!
interface GigabitEthernet1/0/17
 description user-desk-117
 switchport access vlan 20
 spanning-tree portfast
 speed auto
 duplex auto
end

Що це означає: Порт не примусово. Якщо б ви бачили speed 100 або duplex half, ви б одразу мали відповідь.

Рішення: Якщо порт примусово налаштований — виправте його (встановіть auto, якщо немає документованої причини). Якщо він на auto — зосередьтеся на парах, обжаттях, проміжних пристроях або несправних портах.

Завдання 13: Використайте тест трафіку, щоб довести пропускну здатність порівняно зі швидкістю лінку (iperf3)

cr0x@server:~$ iperf3 -c 10.20.30.40 -P 4 -t 10
Connecting to host 10.20.30.40, port 5201
[SUM]   0.00-10.00  sec   112 MBytes  94.1 Mbits/sec  0             sender
[SUM]   0.00-10.00  sec   111 MBytes  93.2 Mbits/sec                receiver

Що це означає: Ви досягаєте стелі 100 Mbps (з урахуванням оверхеду). Це підтверджує, що симптом — не «додаток повільний», а лінк справді обмежений.

Рішення: Перестаньте тюнити продуктивність на рівнях 4/7. Спочатку виправте узгодження лінку.

Завдання 14: Визначте, чи задіяний USB NIC (lsusb)

cr0x@server:~$ lsusb | grep -i ethernet
Bus 001 Device 006: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter

Що це означає: Ви використовуєте USB гігабіт-адаптер. Вони можуть бути цілком нормальними, але також частими винуватцями дивних узгоджень і EEE-проблем.

Рішення: Протестуйте іншим адаптером або прямим NIC, якщо можливо. Якщо проблема зникає — перестаньте звинувачувати будівельну кабельну систему. Вона була не зовсім невинна, але й не головна винуватиця.

Завдання 15: У Windows підтвердьте узгоджену швидкість (PowerShell)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetAdapter | Select-Object Name, Status, LinkSpeed"
Name      Status LinkSpeed
----      ------ ---------
Ethernet  Up     100 Mbps

Що це означає: Windows погоджується на 100 Mbps. Це не проблема лише драйвера Linux.

Рішення: Перевірте кабель, конфіг комутатора і проміжні пристрої. Якщо лише одна ОС бачить 100 — зосередьтеся на налаштуваннях драйвера (Speed & Duplex, EEE) для цієї ОС.

Завдання 16: Скинути в Windows розширені властивості адаптера (Speed & Duplex)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetAdapterAdvancedProperty -Name Ethernet | Where-Object DisplayName -Match 'Speed|Duplex' | Select-Object DisplayName, DisplayValue"
DisplayName       DisplayValue
-----------       ------------
Speed & Duplex    Auto Negotiation

Що це означає: Адаптер встановлений на auto, що зазвичай правильно. Якби це було примусово 100, ви б мали самозавдану проблему.

Рішення: Залишайте на auto, якщо лише не діагностуєте відому помилку. Примусове встановлення гігабіта на одному кінці — це як створити новий інцидент, «виправляючи» поточний.

Три корпоративні міні-історії з бойових умов

Міні-історія 1: Інцидент, спричинений хибним припущенням

У середній компанії з гібридним офісом фінансова команда поскаржилася, що «файловий шар повзе». Команда сховищ перевірила NAS: диски в нормі, CPU в нормі, мережеві графіки нудні. Тож провина перекинулась — бо провина завжди мігрує — на «нову політику SMB signing» і «оновлення Windows».

Молодший адміністратор зробив те, що робить кожен: замінив патчкорд на столі користувача. Лінк повернувся до 1 Gbps. Тікет закрито. Усі перейшли далі. Через два дні той самий користувач відкрив той самий тікет. Кабель знову замінили. Тимчасове виправлення знову.

Нарешті хтось зробив неоригінальну річ: простежив шлях. Патчкорд столу → настінна розетка → патч-панель → комутатор. Вони пересунули порт патч-панелі користувача на інший порт комутатора і проблема зникла назавжди. Справжня причина — один порт комутатора, фізичний інтерфейс якого став нестабільним; він узгоджувався на 100 за певних температур і навантаження і час від часу давав FCS помилки.

Хибне припущення було «це кабель, бо заміна кабелю допомогла». Реальний урок: тимчасова кореляція — не причина. Заміна кабелю змінила натиск контакту і перепідключила контакти, маскуючи справжній компонент, що відмовляв.

Після виходу порту з експлуатації вони задокументували правило: якщо проблема 100 Мбіт/с повторюється двічі в тому самому місці, припиніть міняти патчкорди і почніть ізоляцію портів та обжаттів. Це правило запобігло майбутнім дивним повторенням.

Міні-історія 2: Оптимізація, що відкотилася

Інша організація вирішила стандартизувати десктопні порти на 100 Мбіт/с «щоб зменшити широкомовні бурі і підвищити стабільність». Це продавали як акуратну оптимізацію: менше шуму, менше ризику, менше тікетів. Це також звучало приємно впевнено, що діє як магніт для деяких нарад.

Певний час все здавалося добре. Більшість офісних навантажень не кричали. Потім компанія запровадила шифровані резервні копії кінцевих точок по LAN у нічний час. Раптом щоденне завдання тяглося до ранку. Ноутбуки все ще завантажувалися, коли люди приходили, і інтерактивна продуктивність провалювалася. Хелпдеск потонув у скаргах «VPN повільний» і «Wi‑Fi лагує», бо користувачі не розрізняють методи доступу; вони просто відчувають біль.

Інженери виявили очевидне заднім числом: деякі кінцеві точки були на гігабіті і завершувалися швидко, інші штучно обмежені на 100 створювали довготривалі затори. Мережа не стала більш стабільною. Вона стала більш передбачувано перевантаженою.

Відкат торкнувся не лише пропускної здатності. Деякі порти були примусово на 100/full, поки кінцеві точки залишалися auto. Невелика кількість неправильно узгоджувалась, спричиняючи симптоми дуплекс-несумісності і шторм ретрансляцій, що виглядали як «випадкові проблеми мережі».

Вони відкотили політику: дефолт — auto/auto на 1G, а широкомовні бурі вирішували реальними засобами (storm control, сегментація, DHCP snooping, належна гігієна комутаторів). Оптимізація була коротким шляхом. Короткі шляхи — добре, поки вони не стають дорогою.

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

Команда дата-центру мала практику, якою ніхто не хвалився: кожен новий мідний проклад сертифікували тестером і маркували кінці, включно з ID портів патч-панелі. Вони також тримали невелику запечатану коробку з відомими хорошими короткими патчкордами, використовуючи їх лише для діагностики.

Одного дня вранці новий стійка серверів прийняли в експлуатацію і половина вузлів узгодилась на 100 Мбіт/с. Звичний хаос намагався утворитися. Але команда мала квитанції: горизонтальне кабелювання сертифіковане, а патчкорди з розгортання були з нової партії, яка не була валідувана.

Вони підключили один сервер відомим добрим кабелем із запечатаної коробки: відразу 1 Gbps. Протестували кілька кабелів з нової партії: багато пар виявилися несправними. Не «низька якість» — справді дефектні.

Оскільки команда мала маркування кінців і записи сертифікації, діагностика не перетворилася на суперечку. Вони ізолювали змінну, підтвердили її, замінили всю партію і продовжили роботу. Без геройства. Без пізньої ночі.

Ось сенс нудних практик: вони не роблять вас розумним. Вони роблять вас готовим.

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

1) «Це Cat5, отже не може робити гігабіт»

Симптом: Лінк узгоджується на 100; хтось вказує на напис на оболонці кабелю.

Корінна причина: Плутанина між категорією і реальною якістю встановлення. Багато Cat5 прокладів можуть робити гігабіт на коротких відстанях; багато Cat5e провалюються через погані обжаття.

Виправлення: Не сперечайтеся з етикеткою. Протестуйте, підключивши відомо хороший короткий кабель прямо до комутатора. Якщо отримаєте 1G — сертифікуйте структуровану мережу або перетягніть контакти в розетці/панелі.

2) «Примусове встановлення швидкості вирішує проблеми узгодження»

Симптом: Хтось примусово ставить 1000/full на хості або комутаторі; лінк стає нестабільним або лишається на 100.

Корінна причина: На практиці гігабіт очікує autoneg. Примушення однієї сторони може зламати master/slave таймінги і спричинити мовчазні відкатки.

Виправлення: Використовуйте auto/auto, якщо ви не працюєте навколо відомої задокументованої помилки — і тоді виправте помилку, не живіть з тимчасовим обходом вічно.

3) «В журналах додатка немає помилок, отже це не мережа»

Симптом: Користувачі скаржаться на повільність; додаток виглядає нормальним; лінк на 100.

Корінна причина: Мережа працює, просто обмежена. Багато додатків не логують «ваш NIC сьогодні погано узгодився».

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

4) «Це має бути комутатор, комутатори — погані»

Симптом: Декілька кінцевих точок на різних портах показують 100 Mbps, періодично.

Корінна причина: Часто це партія поганих патчкордів, проблемна рядок патч-панелі або нова модель дока, що була розгорнута.

Виправлення: Знайдіть спільність: та сама патч-панель, той самий док, та сама партія кабелів. Використовуйте LLDP для прив’язки портів і кореляції.

5) «Wi‑Fi тут швидший за Ethernet»

Симптом: Ноутбук отримує кращі швидкості по Wi‑Fi ніж по дроту.

Корінна причина: Дротове підключення застрягло на 100 через пари/узгодження; Wi‑Fi підключається на вищі PHY-ставки і тимчасово дає кращу пропускну здатність.

Виправлення: Розглядайте це як проблему прокладу/порту, а не як докір Ethernet як концепту.

6) «Він у повному дуплексі, отже не може бути фізичним»

Симптом: Дуплекс показує full на обох кінцях; проте 100 Mbps та помилки присутні.

Корінна причина: Повний дуплекс може існувати на 100, поки тренінг гігабіта провалюється через відсутню пару або поганий SNR.

Виправлення: Шукайте CRC/FCS помилки і ізолюйте сегменти кабелю. Повний дуплекс — це не повний висновок про здоров’я лінку.

7) «Порт називається GigabitEthernet, отже він гігабітний»

Симптом: Ім’я портy на комутаторі натякає на гігабіт; узгоджена швидкість — 100.

Корінна причина: Здатність порту — не те саме, що фактичний результат. Лінк вибирає те, що він може надійно підтримувати.

Виправлення: Перевірте фактичну узгоджену швидкість з обох кінців і що рекламується. Потім виправте причину, чому узгодження не досягає 1000.

8) «Ми міняли кабель двічі; це не кабель»

Симптом: Декілька замін кабелів не допомогли.

Корінна причина: Кабель — не єдиний фізичний компонент. Розетка, панель і порт мають значення. Також: люди продовжують міняти той самий сумнівний запас зі скриньки «різні кабелі».

Виправлення: Використовуйте відомий добрий протестований патчкорд, обійдіть проміжні пристрої і переключайте порти. Розглядайте діагностику як ізоляцію, а не як ритуал.

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

Покроково: ізолюйте проблему за 20 хвилин

  1. Підтвердьте симптом: запустіть ethtool (Linux) або Get-NetAdapter (Windows) і зафіксуйте швидкість/дуплекс/autoneg.
  2. Ідентифікуйте switchport: використайте LLDP якщо доступно; інакше трасуйте через MAC address tables (попросіть NetOps якщо потрібно).
  3. Перевірте конфіг портy: переконайтеся, що швидкість/дуплекс — auto, якщо немає документованого винятку.
  4. Перевірте лічильники порту: FCS/CRC помилки вказують на фізичний рівень; чисті лічильники вказують на конфіг або кінцеву точку.
  5. Обійдіть проміжні пристрої: при можливості видаліть доки, роз’єднювачі, інлайн-екстендери та настінні панелі.
  6. Відомий короткий кабель до комутатора: це найшвидший тест фізичної ізоляції.
  7. Поміняйте порт комутатора: перемістіться на інший порт з відомою конфігурацією і спостерігайте узгодження.
  8. Протестуйте інший кінцевий пристрій: якщо інший хост узгоджується 1G на тому ж тракті — підозрюйте первинний NIC/док.
  9. Вимкніть EEE як тест: якщо це виправляє флапи або вперте узгодження — вирішіть постійну конфігурацію.
  10. Задокументуйте корінну причину: «поганий патчкорд» прийнятний лише якщо ви можете відтворити відмову з тим кабелем або підтвердити його тестером.

Операційний чекліст: що стандартизувати, щоб це припинилося

  • Тримайте запечатаний набір відомих хороших коротких патчкордів лише для діагностики.
  • Вимагайте сертифікацію (або принаймні тест пар) для нових прокладів і робіт на патч-панелі.
  • За замовчуванням встановлюйте порти доступу комутаторів на auto/auto і документуйте будь-які примусові винятки з власником і причиною.
  • Відстежуйте моделі доків/USB NIC і версії прошивок; ставтеся до них як до мережевих пристроїв, бо вони такими є.
  • Налаштуйте сповіщення по лічильниках помилок портів (FCS, input errors) і флапах лінку; «100 Mbps» часто супроводжується фізичною нестабільністю.

Факти та історія, яка дійсно допомагає

  • 100BASE-TX використовує дві пари; 1000BASE-T — чотири. Одна мертва пара часто означає «100 Мбіт/с назавжди».
  • 10BASE-T і 100BASE-TX часто можуть протягнутися по поганому кабелю; гігабіт менш поблажливий, бо штовхає більше біт через той самий мідний кабель.
  • Autonegotiation стала необхідною зі зростанням швидкостей. Дні, коли можна було безпечно всюди примусово виставляти налаштування, минули для більшості середовищ.
  • Ethernet по кручений парі спроектований дешевим і стійким, тому він працює взагалі через офісні стіни і сумнівні роботи з обжаття.
  • Етикетки категорії не гарантують продуктивність. Якість установки (радіус вигину, обжаття, перехресні наводки) часто домінує над фактичною маркуванням.
  • Гігабіт по мідні використовує echo cancellation і складний DSP. Саме тому PHY може «тренуватися» і вирішувати, що канал недостатньо хороший.
  • EEE (802.3az) з’явилося, щоб знизити споживання у простої. У деяких комбінаціях пристроїв воно також принесло «загадкові флапи».
  • Імена портів комутаторів можуть вводити в оману. «GigabitEthernet» — це можливість, а не гарантія узгодженої швидкості.
  • Патчкорди ламаються частіше, ніж очікують, бо їх згинають, перекочують стільцями і часто міняють — їхнє життя важче, ніж у вбудованого кабелю.

Одна парафразована ідея від W. Edwards Deming ідеально підходить до мереж: парафразована ідея — «Без даних ти просто ще одна людина з думкою». — W. Edwards Deming

Жарт №2: Autonegotiation — як дипломатія: коли обидві сторони відмовляються говорити, всі відкотяться до старих домовленостей.

Питання й відповіді

Чому поганий кабель часто все ще працює на 100 Мбіт/с?

Тому що 100BASE-TX потребує лише дві пари і терпить більш маргінальні умови сигналу. Гігабіт вимагає всіх чотирьох пар і кращих характеристик каналу.

Якщо в мене Cat6, чому я все ще застряг на 100?

Бо категорія — це не те саме, що правильно змонтований, цілий шлях. Cat6 патчкорд, підключений до погано обжатого keystone-джеку, все ще залишається погано обжатим джеком.

Чи є примусове встановлення 1000 Мбіт/с валідним рішенням?

Майже ніколи. Примусове встановлення — хороша діагностична техніка лише якщо ви розумієте обидва кінці і можете безпечно повернути назад. У продакшні auto/auto — дефолт з причини.

Чи може це бути дуплекс-несумісністю навіть якщо обидва кінці кажуть «full»?

Якщо обидва кінці справді узгодили full і погоджуються, дуплекс-несумісність малоймовірна. Але якщо одна сторона примусова, а інша — авто, авто-сторона може неправильно визначити дуплекс. Завжди перевіряйте конфігурації обох кінців, а не лише поточний вивід.

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

Візьміть кінцеву точку до комутатора і підключіться відомим хорошим коротким кабелем. Якщо там домовляється 1G — комутатор, ймовірно, у нормі, а проблема в структурованому кабелюванні.

Чи справді доки та USB Ethernet адаптери спричиняють узгодження на 100 Мбіт/с?

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

Як дізнатися, чи порт комутатора налаштований на обмеження 100?

Перевірте running configuration для інтерфейсу. На багатьох комутаторах ви побачите явний speed 100 або подібне. Якщо там auto, але все одно 100 — порт реагує на узгодження/фізичні умови.

Мій лінк 1 Gbps, але продуктивність все ще погана. Це пов’язано?

Інша проблема. Тепер ви дивитесь на затори, налаштування offload у CPU, невідповідний MTU, вузькі місця в сховищі, втрати пакетів або обмеження на рівні додатку. Не ганяйтеся за 100 Мбіт/с, коли у вас 1 Gbps лінк.

Чи може один зігнутий контакт в RJ-45 спричинити це?

Так. Зігнуті або забруднені контакти можуть періодично обривати пару. Лінк може зупинитися на 100 Мбіт/с, бо тренінг гігабіта не вдається. Інспектуйте та тестуйте відомими добрими компонентами.

Чи безпечно вимкнути EEE скрізь?

Зазвичай так в корпоративних доступних мережах, особливо якщо ви вже помічали проблеми. Енергозбереження зазвичай невелике порівняно з операційними витратами на нестабільні лінки. Перевірте на вашому обладнанні.

Висновок: наступні кроки без марної трати дня

Якщо ваш Ethernet лінк застряг на 100 Мбіт/с, не починайте з фольклору. Почніть із доказів.

  1. Перевірте узгоджену швидкість/дуплекс/autoneg на хості і комутаторі.
  2. Ідентифікуйте точний порт комутатора (LLDP допомагає) і перевірте лічильники CRC/FCS.
  3. Ізолюйте шлях відомим коротким справним кабелем прямо до комутатора; обходьте доки і проміжні пристрої.
  4. Якщо це фізично — виправте фізичне: перетягніть контакти в розетці/панелі, замініть дефектну партію патчкордів або виведіть з експлуатації проблемний порт.
  5. Якщо це конфігурація — нормалізуйте до auto/auto і документуйте будь-які винятки так само, як правило фаєрвола: з власником і причиною.

Мета не в тому, щоб «домогтися 1G один раз». Мета — щоб він тримався на 1G після перезавантажень, подій лінку і наступної людини, що «прибирає» шафу.

← Попередня
Підготовка до завершення підтримки Windows 10: що робити, перш ніж панікувати
Наступна →
Фронтенд: шаблон UI пошуку, який робить документацію «миттєвою»

Залишити коментар