Незбіжність дуплексу на порту VPN-шлюзу: читайте обидва кінці

Копіювання файлу через тунель завмирає на секунду, поновлюється, а журнали VPN нічого не показують. Застосунок звинувачує мережу, мережа звинувачує застосунок, а порт комутатора ввімкнено вже одинадцять місяців. Цей розбір починається з паузи і рухається назовні до фізичного каналу: що порт насправді робить, що робить дальній кінець і що робили лічильники, поки ви спостерігали. Це варто зробити перш ніж хтось торкнеться налаштування дуплексу.

Почніть із паузи, а не з порту

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

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

Це важливо, бо в незбіжності дуплексу є підпис: помилки з'являються лише під навантаженням, у напрямку трафіку, тоді як малі ping та інтерактивні сеанси залишаються бездоганними. Якщо й трафік у простої зазнає невдачі, спершу пошукайте в іншому місці.

Прочитайте робочий режим на обох кінцях

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

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

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

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

Як виглядає випадок 10/100 на половинному дуплексі

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

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

Спостережуваний доказ — це суміш помилок, що існують лише в одному напрямку: помилки FCS або CRC на боці повного дуплексу, колізії або пізні колізії на боці половинного дуплексу і пропускна здатність, що руйнується під навантаженням, тоді як затримка лишається нормальною в простої. Ця асиметрія і є підписом. Канал, який просто перевантажений, деградує в обох напрямках і весь час.

Змінюйте обидва кінці разом, зі шляхом назад

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

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

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

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

Переконайтеся, що лічильники зрушили на краще

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

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

Канал без нових помилок під тим самим навантаженням — це доказ, якого вам бракувало. Канал, який досі помиляється, або той, де лічильники взагалі не рухалися, відправляє вас до наступної межі, а не глибше в суперечку про дуплекс. Обидва результати — це поступ, а це більше, ніж може дати файл конфігурації. Не пропускайте друге читання лише тому, що перше виглядало правильним.

Запишіть числа до і після в заявку з відмітками часу. Саме цей запис перетворює «VPN став працювати краще» на те, на що може спертися наступний інженер.